Ben A.M.

From childhood onward Ben has had a passion for the video game industry and in some way or another he's striven to be apart of it in any way he could. Whether that meant working at a mom-n-pop video game store, freelance writing reviews and articles for websites, or writing the story and designing levels for indie games. He has always had a love of for the medium and is "really good at writing about himself in the third person." [email protected] Skype-ID: GuardianKnux

[benamgames]

Post GDC 2015 thoughts

Last week was busy for me. Between interviews, arranging family business, and going to GDC, my legs were pretty much made of jelly by the weekend. Now that I’ve had time to reflect and rest up, I wanted to jot down a few quick thoughts about the event. 

Less full 

PAX east was unfortunately being held on the same week. So a lot of developers (and press people I’d assume) had to either choose one event to cover or just spend a day here and a day there. It was kinda nice to not be super crowded. In fact, now that I think of it, I can’t remember a single instance of accidentally brushing shoulders with someone. Weird. 

On the plus side it made talking to people at booths much easier than in the past. Most booths I could just randomly walk up to them and have a conversation about whatever. 

Less hands on time with new stuff

Last year I remember you could just stand in a short line to try out Oculus demos or Morpheus demos. I remember having a nice long chat with a Developer at Valve last year where I played a couple of games with the Steam Controller and talked general design with her. This year you had to have appointments just to see Valve and they seemed to be booked full right away. 

The few things there was to try out were a little underwhelming. An assault rifle controller that was too loud to ever use in a real home. One Oculus demo that was “meh.” A giant swing set thing that was... weird. Some poorly designed slot machines that required a developer there at all times to explain if you won or not. Nothing all that amazing.

There was however a really interesting area called “alt.ctrl.” where you could play a couple dozen games that all had unique ways to control them. One game you wore a mask and had to touch spots on the mask to play. The most interesting/fun/dumb game there to me was Butt Sniffin Pugs, a game where you use a giant tennis trackball to move around pugs and make them pee and poop everywhere. Pretty great.

It’s dangerous to go alone

I’ve been to GDC a few times now and I have to say, it is way less interesting when you’re by yourself. Last year I went to GDC with a college buddy of mine and that was great! Sure you still strike up conversations with people here n there, but not having someone to just chat with about booths and stuff was kind of a bummer. I had talked to a few people who said they’d be there then dropped out a week before. 

I had a great time as always. I hope next year there’s no scheduling conflict with another big convention

[benamgames]

Developer Blog: Galactic Gunpowder Golf. Part 2 of 2

Hello everyone. I am finally finished with college. It feels great to be done and have our little game project finished too. I created a short postmortem video about our game G3. This was a turn in for our school project and as such it had a pretty strict time limit. The original video I recorded was about 16 minutes long, but it had to be edited down to around 5 minutes and thirty seconds. So to supplement the video, I've written a few thoughts on the past four months of working on this game. Enjoy.

https://www.youtube.com/watch?v=cmx394Pb-AE

These past four months where pretty stressful. There where only two of us who where any good with unrealscript, and even then I wouldn't say we were really any good. We just knew how to google things. So there was lots of trial and error when it came to scripting. We spent days on problems that a skilled programmer would have taken minutes to do. It's was pretty frustrating. But we pulled through.

What I didn't like during development.

During the end of the first month/beginning of the second month, I had to create all of the scripts. Scripts for making the guns work, scripts for shooting the ball, changing the powers of each shot, and displaying it all on the HUD. Because all of there things where so interconnected, only one person could realistically work on it at a time. And since it's hard to jump into someone else's code, that fell entirely on me. It was very stressful and I pulled multiple 48 hour all-nighters with no sleep so we could have the ball and guns working as intended. Doing this meant that I didn't have as much time as others to work on my personal level. So it left me feeling pretty inadequate, since everyone else had cool and polished levels to show off and I would just have to say "yeah my level looks like crap... but the ball works at least."

My favorite part was just screwing around with the ball physics. I wish we had more time to add more stuff to do in the playground/credits screen. I had more fun shooting the ball into the barrels in the tutorial than playing most of our levels.

What I did like during development.

My favorite part was just screwing around with the ball physics. I wish we had more time to add more stuff to do in the playground/credits screen. I had more fun shooting the ball into the barrels in the tutorial than playing most of our levels.

Originally we where going to be just like real golfing, in that we would have all of the same clubs you would in a real golf bag. That means 3 wood-guns, 9 iron-guns and a putter. That proved to be too much clutter. There's a reason why the Doom style of running around with 20 guns on you stopped being popular and the more concise Halo-esk style became popular. Less stuff to manage so you can focus on the game. So then we chopped it down to just three guns. Wood for long shots, iron for medium shots, and putter for shot ones. But that didn't give us enough room to play with, you didn't feel like you had great control over where the ball shot.

I consider myself a better systems design rather than a level designer. So my favorite parts of development where taking this problem and finding creative solutions to them. I solved there problems in two ways. 

1. Each gun would have an adjustable power meter. Where some golf games have a moving power meter that would slide back and forth, our game would have a fixed power meter that the player could adjust with the mouse wheel. This felt great, but it created a problem where now the Iron gun was somewhat obsolete. The wood gun could now be adjusted to fire about a weak as the iron gun. Our solution to that was to give the iron gun special properties. 

When do you use an Iron club in real golf? Sure, you use it when you don't want to go as far as a wood club, but you also use it to hit the ball higher so that when it lands on the ground, it has less horizontal moment and doesn't roll as much. So we decided to give the Iron gun special properties so that the balled fired from the iron gun will come to a complete stop when it touches something. That way you can shoot near edges and not have to worry too much about the ball falling off. This fixed our "Iron gun is useless" problem and fixed a smaller problem where some shots where a bit too easy to roll the ball off of the level.

2. We still had the problem of the player not knowing how far the ball will fly at each power level. To fix this, we created a "trace shot." At any time, with any gun (besides the putter), and at any power level you can right click instead of left click and you will fire a trace shot that travels identically to a real ball, except it doesn't cost you a shot, and if it touches anything the trace shot is destroyed. This lets the player take free shots and watch where the ball would go. This was fun to implement and made the game much more accessible. 

I really enjoyed my time on this game, even though I was stressed out a bunch early on. I'm made some talented friends along the way. I look forward to whatever comes next.

[benamgames]

Developer Blog: Galactic Gunpowder Golf. Part 1 of 2

I have been super busy lately. Of course I am still working on Run or Die, but in addition to that I have been working on our final project for school. I've been wanting to write a devblog about our project for some time now, so let's do it! Here's what I've been doing for the past month and a half. 

Week  0: Every student in our class is asked to create a high concept pitch of a new game idea that we could possibly create in the last four months of school. I procrastinate and come up with something in the last 3 hours before the submission is due. My pitch is G3: Galactic Gunpowder Golf, a first person game about playing golf by shooting giant golf balls out of cannons in space! Lots of very interesting unique mechanics in the original pitch, not just a standard golf game with a space theme.

Everyone submitted their game pitches and the teachers would gather together and look at every singe one. Out of the 30-ish people in that months class who submitted pitches, only 8 of them where deemed acceptable game pitches. Mine was one of them. 

Here is my original unedited pitch. Errors and all.*

Galactic Gunpowder Golf We had to ditch the multiplayer aspects of the game due to time constraints.

*On a side note, the teachers told me that this was the best tagline of any game pitch they have ever received in their years teaching at the school.

Week 1: Every student is assigned to a team of 5 or 6 people, our team has 5. Right off the bat we have a problem, one of our teammates is having PC problems and has to drop out that month. So we're down one member immediately. But it's not the worst thing in the world. 

Now we have to decide two things. 1. Who will be the team leader? 2. What game pitch will be decide to work on? We are allowed to choose any of the 8 selected game pitches to work on. Each team cannot select the same pitch and it's first come first serve, with the exception being if you are the one who created the pitch, you can veto another team from making it as long as your team works on it. We decide that I will be the team leader and that we are going to work on my Pitch G3.

Weeks 2 - 4: We finally get to work. We need a fully playable game by the end of the month. Not feature complete, not art complete, not level complete. We jut need one playable level and our basic mechanics working, a prototype/proof of concept. We are told to use Unreal Engine 3. Yes 3. We found out much later that we could have used UE4 (which we would have rather done), but the wording the teachers used made it sound as though we had to use UE3. Turns out every other team thought the same. Oh well. We get jammin' and pumped out a fun little map.

Weeks 5 - 7: Now that we've got our proof of concept, we are tasked to create our GDD. Why wait five weeks before we make our design doc? Because we needed to make sure that our game was worth our time. If we spent the first month making our proof of concept and it turned out to be garbage, then we'd have to come up with a new game to make. So if we spent time making a GDD for a game that we ultimately don't work on, then we just wasted a bunch of our time for nothing.

I created our GDD in week 5, then made some revisions in week 7. You can check out our GDD as of Week 7 right here.

At this point we have our core mechanics finished. We have our shooting mechanics (seemingly) finished. We have the basic movement and world rules implemented. We've got multiple maps working, menus working, score tracking working, interactive objects working. Really, the only core thing we don't have finished is an end-of-level score screen and a tutorial, and we should have that done soon-ish too. After that is done we can get into the nitty-gritty level designing for each map and then we'll focus on sound and art afterword.

It's not much to look at right now, but it's coming along really well. The floating space islands motif is going to look really great once it's finished.

The future of the G3 development blog: This initial blog was very bare bones, I just did a basic overview of what happened each week without getting into the nitty-gritty of what happened, what decisions we had to make, or what problems we ran into. I will write the second half sometimes around January or February after graduation. There I will talk about all of the changes I'm sure we will have made by then.  

Stay tuned for more updates on G3!

[benamgames]

Run or Die: Designing a fun and balanced level

Over the past couple of months I have been designing levels for the upcoming endless runner game Run or Die. Its already been Greenlit, so now it's up to the creator and programmer Flow to finish the last bit of polish and for myself to design more levels. Run or Die will be releasing sometime around the end of the year, so watch for it!

So, what do I do on the game? I have been creating all of the Challenge maps (which actually do have an ending) as well as single segments for the main Endless mode. I wanted to go into my thought process on creating challenge maps and show how I design a level.

In Run or Die, your character can have two abilities (out of a possible 5) equipped at a time. In the endless mode you abilities are randomly swapped out every once in awhile during safe zones. On challenge maps, you can only use the two abilities that I choose for you for each map. For this example map, the two abilities I chose were Dash and Dive. Dash cancels your vertical momentum and boosts you straight forward. While Dive shoots you diagonally down. Both abilities will break through Spherions, a techno-crystal that will kill you if you run smack-dab into it normally.

Your abilities go on a brief cooldown when you use them.

Dive is one of my favorite abilities because you can cancel out of the dive by using your other ability. This means I can create situations where you need to dive downward and quickly dash out of your dive to get to your destination. This level in particular is designed to be of medium difficulty, so I don't necessarily want the player to be FORCED to dive-cancel just to progress through the level; it should be a fun option that when the player pulls it off, they feel satisfied. That's where Intel Disks come in. Each challenge map has Intel Disks placed throughout it in strategic locations. They should be visible during a normal first run through the map, but not be so directly on the path so that you'd get them all without really thinking.

The difference between the actual game and what I see in the editor.

In the pictures above you see the main character diving through some spherions. You can dive near the edge and use your forward momentum to break through the wall in front of you. The easier strategy would be to dive-cancel using your dash ability to go through the wall. I made sure to give ample vertical space so that you have a good amount of time to realize that you need to dash. However, the Intel is placed close to the ceiling. From the ground, you can't jump high enough to grab the Intel. So the only way to get it is to Dive below the spherions and quickly dash at the top of the room to grab it. Doing this makes the next challenge a little more difficult. Just ahead of you is a length of lasers that you need to jump over. If you dash quick enough, you'll drop down close to the edge of the laser, meaning you'll have to react quicker than normal in order to jump and dash over it.

This one example illustrates my design philosophy quite well: provide a challenge for people who want to get a perfect score, but make sure that there's a simpler option for people who just want to get through the level and cross it off of their list.

I could go through the whole level, but I think that one example is enough to show off what I wanted to talk about. Run or Die has been very fun to work on and everyone involved is great to work with. I can't wait for the full version to be out in a few months. Check it out RunOrDieGame.com

Thanks for reading!

-Ben A.M.-

[benamgames]

School project: Radio Station

I've had a number of small UDK projects for my college classes. One of these early projects was to lead a four person team in creating a small playable short story set in a post-apocalyptic world. We chose to make our story about getting a radio station up and running.  The team members for this project were William Holland, Kyle Nybo, Michael Ruiz, and myself, Ben A.M. So, we used our first initials and called the radio station WKBM.

I was in charge of the basement as well as overall world handler. In order to keep everyone on track and not stepping on each others toes, I created a Persistent map that links each of our four levels together and set up everyone's boundaries. I also quickly set up entrance and exit points on each of our maps. Each map would have a start point where the player has to start out and an end point where the player needs to be by the end of their map. These are all strung together without and loading screens. 

Half of my time was spent managing the team and the other half of my time was spent creating the basement. We were all pretty new to using UDK, so much of what I was doing was a first.First time using AI gun turrets. First time making cutscenes. First time importing new 3D models. 

Here your goal is to run to the back and turn on the generator, then use the catwalks to get back around the gun turrets. 

I also had to set up a fair amount of Kismet. That was actually the most enjoyable part to me, and I loved hopping into Skype calls with my teammates to help them with their kismet as well. Kismet is UDKs visual scripting tool that helps people with limited programming skills like myself get knee deep into the scripts and make custom actions and events. It can get complected when you look at it, but it's all easily understandable after a while. 

Zoom out!

Hundreds of little commands make our maps an interesting little story to play through. And this is just the kismet for my basement area. 

This was a fun little map we put together. We were all pretty new to UDK and only had three weeks to put it all together. It's a bit rough around the edges, but still very playable and quite interesting to look at.

[benamgames]

Incomplete projects

*2017 update - It seems the host site for these games has gone kaput. I will try to get playable links for these games in the future.

We've all spent time working on projects that never saw the light of day. I've got a few games that, due to some reason or another, will likely never be finished. A couple of them are under NDA, but I can show off two of them that are not: Candy Shot 2 and Entity.

Candy Shot 2

Many years ago a game studio that I interned at named Say Design created a flash game called Candy Shot. The graphics were cheap, the audio was just a single short loop, the gameplay was so-so, and my programmer said it was "some of the worst code I've ever seen." However, it preformed surprisingly well. So some years later, a German company hired Say Design to make a sequel. Myself and the programmer were tasked to lead the project and gather a small team to quickly create a newer fresher version of Candy Shot. 

We used an artist friend of ours to handle the art and I called in a musician (Bill Kiley) I met at a game jam the year before to create some music for us. I designed new features, reworked  old ones, and worked with the artist to redesign the UI. Long story short, the German company suddenly reneged on their contract and I'm told they owe a lot of people a lot of money. Oh well.

You can play our half finished game Candy Shot 2 right here. Try playing it on your phones browser, it actually plays really well on mobile!

Entity

Entity was going to be a friend and I's Ludum Dare entry a couple of years back, but as you can probably guess, we didn't finish it. This one does actually have a beginning and ending though. The theme was "you are the villain." You are an unknown dark entity trying to escape from your confinement. Being a creature of darkness, bright lights hurt you. The gameplay consists of you sneaking around the edges of the levels, dashing through small patches of light to get to the exit.

We had more mechanics partially coded in such as guards, some basic combat, moving light sources, but we ran out of time to implement them fully. We had planned to have more art for the levels and the main character, but our artist called in sick only half a day into the game jam. We had no musician or audio guy, so I just bought some audio tracks so we'd at least have something. Not all game jam games come out perfectly. Ours sure didn't. But there's still something fun about the simple light mechanic that I enjoyed making the levels for this game. We always talked about going back and adding in those additional mechanics we had talked about, but the past is the past I suppose.

You can play Entity here.

[benamgames]

I should fill this out.

My blog has been on my mind a lot lately. I keep working on game projects and thinking that it'd be cool to write some of my thoughts up about them, but then I quickly move on to the next thing and forget. We I've set aside some time tonight and I'm going to get as much as I can down before this coffee wears out!

[benamgames]

Three 48 hour games I made - A postmortem

In my latest class we were tasked with making three games using Perlenspiel3. Perlenspiel is an interesting little bit of software that can help you quickly get rudimentary results onto the screen, useful for people like me who are relatively new to programming. Each of these games were made in less than 48 hours.

If you are on Chrome you may get a blank screen and have to click the shield on the right in your URL bar to load unsafe scripts. It's annoying I know.

The first game had to be something interesting to toy around with; not a full fledged game, just something to mess around with while you familiarized yourself with the Perlenspiel software.

Game #1: Sail the Random Seas.

http://dl.dropboxusercontent.com/u/55474080/Sail%20the%20Random%20Seas/cover.html

A toy where you can sail the seas of a pseudorandom world. As you see at the top left of the screen is a 3 by 3 grid of numbers. Every time you reload the game or press "R" those numbers randomize. The top three brown numbers are what determine the brown dirt of your planet. The middle three green numbers determine what areas of your dirt will be green with grass. And the bottom yellow numbers determine what name your planet has. Originally I made every number in the 3x3 gird random, but I was having fun with the game and wondered how difficult it would be to make the numbers non-repeatable, like a Sudoku grid (meaning in the 3x3 grid, every number from 1 - 9 has to be used and cannot be repeated.) While this makes the game have slightly less potential outcomes, I still found it suitably random. Each number on the third row has 9 bits of letters in them.

1 La. 2 Ti. 3 Sa. 4 Ba. 5 Ru. 6 Do. 7 Ku. 8. Ma. 9 Fa. 1 ti. 2 re. 3 pi. 4 ki. 5 si. 6 ra. 7 pa. 8 ka. 9 na. 1 rock. 2 rax. 3 ron. 4 lea. 5 shana. 6 luna. 7 gar. 8 ara. 9...

Now 9 is interesting. For the 9th option, I wanted to have a suffex of a random number (1 - 9). So I have it run a new random number between 1 - 9, and depending on the number, you'll get the suffex of the 1st, the 2nd, the 3rd, and so on.

You can use the Arrow keys or WASD to move the little red ship around the sea. If you sail into the top/bottom and side most edges of the world, you'll go around the globe and appear on the other side. I know it would make more sense if you could wrap around the globe anywhere but... well I was running out of time, so only the edges work right now. Very fun to make.

Game #2:Concatenate.

http://dl.dropboxusercontent.com/u/55474080/Concatenate/cover.html

The second game had to be a puzzle game with five levels. Each level had to have "partial success", meaning that the player had to feel as though they still made progression, still got something done, even if they didn't completely finish the level or main goal.

Concatenate is a game where you control two characters with the same buttons at the same time, only the Blue character's moments are mirrored of the Red ones. Meaning, if you press UP, the Red character will move up, but the Blue will move down. The goal is to get them into the block of their same color. There is no move limit or time constraint. If you finish the level, you move onto the next one. however, the real challenge is trying to beat the Par moves and Perfect moves score that appears at the top right. I ran into a software limitation, where the statusText up top cannot display an updating number AND text at the same time. Odd. So I made the text up top display the number of moves you've made. Press 1 - 5 to skip to any of the 5 levels. In order to get perfect on each level, the player will have to experiment with the games mechanics. one level is specifically designed so that you will always finish one move higher than the perfect goal unless you discover that you can move the Red and Blue into each other to re-position them. Fun to design, I wish I had more time though. I would have really liked to polish the edges on this one.

I am most proud of this next one. Game #3: ---till -------- --the--- -- fog.

http://dl.dropboxusercontent.com/u/55474080/till%20the%20fog/cover.html

The only direction we were given for this assignment, was that it had to be a game with meaningful decisions that could be played multiple times over and the player could have different experiences with it.

A mini-text adventure mystery game. You follow Timothy in an alternate history San Francisco. Try to live until the end and discover every option, as even death can uncover bits and pieces of the mystery.

I loved making this one. When I first decided to write a text adventure, I had no idea what I was going to write about. For the first few hours, the story was pretty jokey, set in Soviet America, with cyborg bears and magical homeless peoples. But, as the hours passed, the story started taking a more serious tone and I had to go back and rewrite most of the silly stuff to make it all fit together. In the end, I think I made a pretty interesting story that doesn't directly spell everything out for you and leaves you to come up with a few answers to the questions. Only one person who played the game noticed the little touch about the Health bar in the finale scene. Noticing that can help clear up a bit about what happened in the end.

I would have liked to spend more time on the game, have simple images, more elaborate dialog options. But, time being what it was, I think I did okay. Also, I read the narrator in the voice of Logan Cunningham, the Bastion narrator.

Here's also a zoomed out look at my dialog flowchart. Sorry not everything is clear. In order to get it all in a single screenshot I had to zoom out to the point where it's all blurry.

I had a ton of fun making these games. I hope you enjoy them. If you'd like, you can check out my DropBox folder and look into the code for each game. I'm sure you'll see some rookie mistakes and some real hacky code, but it gets the job done. 

If you have any critiques or just want to say hi, hit me up! I'm sure I'll be making more things soon.

[bosskeyceo-deactivated20221106]

I think I might have finally recovered from GDC this year. Not actually having to be at the Epic Booth by 10am allowed me to burn the midnight oil each night, imbibing with old friends, meeting new ones, and generally letting our hair down.

This about summarizes what the double dose of PAX and...

[benamgames]

I agree with his statement about indie game devs hating on AAA games. I met quite a lot of indie developers and it's always weird to hear some of them just constantly crapping all over a development process that they have never had first hand experience with.

They often fail to realize that  most of the people who are into indie games now a days would have never even started gaming when they were younger if it weren't for the larger games attracting vast audiences into video gaming in the first place. We as smaller developers need to coexist with larger game makers. One thing I heard more than a few times at GDC was individual game makers saying things like 'all these big budget games are just cookie-cutter BS. Games like Halo and CoD are all garbage.' To look at a franchise that sells millions and completely write them off because you're indie is foolish. To think there there are no lessons to learn from games that regularly have millions of people playing them means only one thing; you are too short sighted of a developer.

[benamgames]

Pumpin' 'N Jumpin postmortem

Last weekend I participated in the 2013 Global Game Jam. I felt like writing about the process of putting our game together, both because it'd be interesting to show some people how we work and because I felt that I needed to get the process out of my head. Writing things down usually helps cement something in my head. So even if nobody reads this, if will be good for me to get it out. You may wish to play the game first, before you read about what went into making it. You can click the "play it now" button here http://globalgamejam.org/2013/pumpin-n-jumpin

So let's start at the beginning. At the Global Game jam you must make a game that has to do with a theme that is only announced right when the jam starts. The theme we had to design around was the sound of a heartbeat. Right off the bat we started thinking of different games to make, but none of them were all to interesting. An Innerspace like game that would be a dual joystick shooter set inside a persons body. You'd have to travel to the heart and fight off clogged arteries. A Zelda style puzzle game where you have four rooms based on the four chambers of the heart. You'd have to solve them all to save the heart. A simple rock band-ish rhythm game where you'd have to keep the beat of the heart in tune to a song.

We bounce around ideas for about 40 minutes to an hour before we landed on our idea. A runner game (like Canabalt) combined with a heart beat rhythm game. You'd be taking a transplant heart to a hospital and have to keep the heart beating the whole way in order to win. We still threw around a few other ideas before eventually I said "a Zelda style game I've played, a dual joystick shooter I've played, but out of all of the game ideas we've pitched, I don't think I've ever played an runner/rhythm game." So it was decided.

Jonny (primary coder @randuhmm on Twitter) started right away on making a character then making it jump. Al (secondary coder @AlSweigart) got started on the heart pumping minigame, which we quickly decided should be an EKG machine below the character. I gave some direction to our artist Duncan (@Dunkr) and told him to just work on the main character for now while I draw a rough mock-up of how the screen should look. His original art was too big and eventually had to be redone, but it served the purpose for now.

                            Our original hero         Our final smaller hero

  Within an hour or two I had written up most of the design doc. The only thing that wasn't finished was the dialog (yes you heard me, there was going to be dialog in this game.) I added on extra dialog here and there when I felt like it. You can see the entire design doc for Pumpin' 'N Jumpin' right here http://i.imgur.com/xTwp7lX.jpg. As you can see right on the first page, I subscribe to the GATORS way of organizing the game. That is where you write out the Goals, Actions, Terminating conditions, Objects, Rules, and Setup for the game. It is not always necessary for every game to have a GATORS list, but I often find that going through these and trying to put everything I can think of in them helps me greatly. I then did a quick MS paint mock-up just to help our artist have a little glimpse into what I had in mind.

A few hours form the start we met up with a musician named Salem Kebede and he got to work on making us a song. He had a few other project to juggle, so he didn't stay at our area with us the whole time. I took care of the level design and editing while the guys worked on art and code. From then on we jammed for the next two days.

This is what the game looked like for most of its development

We had to make some serious changes and cuts on the last day. Some good, some not so good. We made a change where now your character had visible hearts as health, where as before there was a more convoluted green/yellow/red system. We didn't have time to add in the sound effects. I had made around 20 or so sound effect for the game that we just didn't have time to put in. We unfortunately had to axe the opening tutorial, which would have been an ambulance ride where at first you just are doing the EKG minigame of hitting the spacebar when the line on the EKG was over the circle. You'd have to get three in a row in order to recover one point of health. The ambulance would have crashed, there would have been dialog, then you'd start off with running and jumping over some simple jumps before the game of doing both EKG and jumping would start.

We also had to get rid of the dialog, which I felt was the biggest cut. The game's tone is so silly, the level design is crazy and filled with murderous birds that start picking up cars and even at one point still spell out in the sky "Die "Dr." Love," which is the name of your character. There is also quotes around "Dr." and later when you'd have reached the end, everyone at the hospital is named "Real Doctor." As random as it sounds, all of that had an explanation. I think that taking away the humor really did a disservice to the game. But, it had to be done or we would have never finished the game. As it was we were working on it down to the very last minute.

The cut crashed ambulance with the "Driver guy" who would tare out his own heart as a replacement for the heart he squished in the crash. Also he'd occasionally talk to you as a ghost while you were running... he is kind of an idiot

In the end we wound up being a huge hit at the jam! After an hour of playing everyone's games, we all sat down and took an online survery to vote for 12 different categories, like best 2D art or least commercially viable game. We wound up winning Most interesting use of the theme, most fun, and voters choice. We weren't expecting anything. Especially since in my mind we had cut so much, it felt like it was just a shadow of what we has aspired to. I truly am honored that people thought so highly of our game.

Thanks for listening to the ramblings of a game designer. Till next time!

[benamgames]

Post game jam thoughts

Yesterday we finished the Global Game Jam. My mind and body are still a little off, do to the fact that I (and coder Jonny Morrill @randuhmm) only slept roughly 4 to 5 hours the entire weekend. This was my first successful game submission to a jam, as we ran out of time and didn't submit our game for the last Ludum Dare.

I'm going to write up a postmortem about our game, show off the design doc, and talk about future plans at a later date, perhaps tonight if I have the time. But, for now I want to talk about the game jam and the "jam experience" itself. 

The first hour - pre-team forming - 5:30 PM: I went to the jam with a good friend of mine Jonny (mentioned above) and really had no idea what to expect. What we found was a great event space with around 100 people or so ready to make games. As we watched the keynote videos a random person (Al Sweigart @AlSweigart) came and sat at our table. We both were shocked to realized that we actually knew each other; we had met twice before through a mutual friend. He is a coder as well, so now we have three people. After some mingling we paired up with an artist (Ducan Robson @Dunkr) and set off on trying to come up with a game concept.. but I'll get into our game (http://globalgamejam.org/2013/pumpin-n-jumpin ) in another post. A few hours later we got in contact with a musician named Salem Kebede (who doesn't yet have a twitter but if you like his stuff contact him at [email protected]) who was working on a few project at once, but still had some time to work with us.

During the 48 hours there I made sure to take some time here and there to go walking around and talk to other jammers to see how there games were going. This was actually one of the most fun things about the jam. Talking with others and seeing their initial ideas come together was exhilarating! Meeting some people that I knew only from twitter, talking design with people, and seeing peoples different approaches to the theme was a blast. But my favorite thing to see at the jam was ironically same thing that I dreaded the most. Cuts.

Cutting features and ideas happens all the time in games, but especially so in game jams. Just about every team had to make cuts. At least everyone I talked to did anyway. Watching twitter the last few hours and seeing people tweet about cutting half of their game was great! Not because I like watching people fail (trust me, we had some deep deep cuts on our game) but because I love seeing people make those last minute innovations to save their game. One dev (who didn't submit their game soI can't find his name on the site, sorry dude. He works at Sledgehammer games if I remember correctly) who was working by himself was making a kinect game and realized in the last few hours that it was never going to work. So with three hours to go he scrapped the whole thing (including the theme) and made what amounts to a two player Twister/Simon says mash up. And it was actually really fun!

All in all, the jam was a blast. A very noisy(our site was over a night club that played house music till 4 AM every night), tiring, and sometimes a bit smelling blast! I'll definitely be there next year.