*This post was written November 2014, a month before the release of Run or Die.

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 did I do on the game? I created all of the Challenge maps 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 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 right. 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 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 makes you feel cool when you pull it off. 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 the intel is to Dive below the spherions near the edge of the wall and quickly dash at the top of the room to grab it. However, there is another danger. Doing this maneuver makes the next obstacle a bit 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.-

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.

Baby faced Ben

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.” 

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. 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. My 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. 

We had a lot of other random issues, some inconsistencies with how a level would look before it was "cooked", some people not pulling their weight big time, and even the occasional physics wackiness. But when it was all said and done, 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.

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. 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.

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

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.

image

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!