Posts tagged with “user”

Lost? Wondering what you missed? Read Yesterday’s Post!

September 2008 came and went, and we had a few prototypes for what would eventually become Slam Bolt Scrappers. Now it was time to roll the parts we liked together into a mega-prototype to see if we could actually make something more fun that everyone would enjoy.

The features we wanted to keep were: User generated content for making levels, an architecture theme, and fighting mixed in with the building. We also thought that the electricity and water elements from the tree prototype were interesting as well. The stuff that we wanted to fix was the lack of clear goals and lack of level structure. We spent October 2008 jamming in python, and here’s what we came up with.

Right off the bat you’ll notice a lot of differences. The game play was kind of similar to the T-Rex prototype, with a marauding bad guy (in this case a robot) that you could temporarily knock out so you could focus on building. The building was still centered around the idea of picking up I-beams from piles on the side of the screen, but we increased the complexity, allowing the player to build anywhere and asking them to also make sure that every part of the structure was both powered and watered. We also made the fighting more complex, giving the player a gun to shoot beams and a powerful close range punch attack that was stronger depending on how fast the user was moving. Finally there were two lose conditions; run out of money or have your whole building destroyed and you would fail the level.

Making the game 2 player was a very smart decision, as the game was suddenly much more fun when you had someone else playing the game in the room with you. It also gave rise to all sorts of interesting strategies, like “you fight! I’ll build!” Once we put multiplayer in it was clear that it was going to be a central feature for the game.

Perhaps one of the most interesting points of this game is the controls – you’ll notice the XBox buttons showing up on screen, as we initially envisioned the game as an XBLA title (we had a good contact at Microsoft in that department at the time). The trophies in the bottom right corner of the menu even led to unlockable achievements.

The level editor was a neat feature that people liked but ultimately we decided to cut it. Our Microsoft friend pointed out that we’d have problems with ratings once people started submitting levels that spelled out “Fuck” or had a giant penis in it, and we weren’t convinced that it was worth the hassle of adding a feature that could lead to mediocre level design. Ultimately this was the last iteration that featured the level editor as we dumped user generated content from our core feature set.

We still didn’t have an artist on board until the very end of October so much of the art in this prototype was borrowed. We found sprite sheets online for robots from TwinBee and Mega Man X and repurposed those as our player characters and computer controlled bad guys respectively (it was especially weird for me as I played Mega Man X a lot, this robot was much tougher ). To make the background feel like a city we altered the background from SimTower, and to give the game an epic feel we put in some Matrix music by Rob Dougan. The tiles for the building, beams, and pipes were all original art as our artist managed to get us new assets for those at the last second. We were getting close to the point of pitching though, so this would be the last prototype we would make with non-original art assets as we didn’t want to get into legal trouble.

The prototype was neat but our Microsoft contact confirmed our suspicions that it wasn’t strong enough to get a greenlight for XBLA. We therefore set out after this to make an even more polished prototype, and to fix up some of the things we didn’t like about the version we had.

Pros of Construction Robot Prototype:

• Multiplayer was a lot of fun. We decided it would be neat to try out 4 player mutliplayer next time.
• Game felt innovative and different
• Lighting up the building and punching out robots was satisfying, but could get frustrating quickly when it was too hard
• Achievements were cool, people liked them a lot

Cons of Construction Robot Prototype:

• User generated content too much of a headache, not compelling enough
• Building felt too simplistic
• Going back and forth to the edge of the screen got old quick
• Money mechanic was too complicated and confusing, and added almost nothing to the game
• It felt silly to not only have to build but also to have to water and power it, and people weren’t clear on why that was their goal. What was the point?

It’s pretty cool to see how this game is already much closer to Slam Bolt Scrappers than the first attempts. Tune in tomorrow for a run down of iteration 3!

Since the Penny Arcade post and Sony video a few days back we’ve been getting a lot of questions about our design process. So we decided to kick off a 5 day series on the iterations behind getting to the final design of Slam Bolt Scrappers! If you are at all interested in how games get made or are considering getting into game design yourself then this is the series for you. Enjoy!

We opened Fire Hose in September 2008. At the time I was working with Ethan and Sharat, two programmers I knew from MIT. We didn’t have any artists so our skill set was pretty limited. We also didn’t have much in the way of tools or resources, so we were working with stuff commonly available on the interwebs.

Our initial goal was to make a game that was about architecture, and ideally taught the player a bit about construction. We were inspired by the fun of playing with legos and blocks as kids, and felt we could probably make a game that had some interesting roots in that while at the same time allowed players to do things they couldn’t normally do in real life. So we decided to spend a week prototyping some gameplay concepts to illustrate these points. I’m going to share two of them with you now.

The first concept we came up with for Ashdown (our game’s code name) was the Tree Prototype. Our thinking was that it would be cool if we could make a game where buildings organically grew themselves (an idea we would later revisit when with growing weapons out of blocks in SBS). In the game you use the mouse to click and the scroll wheel on the mouse to change the color of the “seed” you are planting – yellow for electricity, blue for water, and green for plant. The goal is to get as many leaves (foliage) as possible. Plant seeds automatically grow when placed on the ground, and yellow electricity seeds grow when there is rectangular steel beams for them to grow on. Blue water just stays on the ground unless it touches electricity and beams, in which case the electricity “pumps” it up the tower. Higher water means the plant can grow taller (meaning more leaves), but plants knock out electricity so you have to be careful. The counters on the bottom display game information.

The game also had a level editor, since at the time we were thinking user generated content (like in Little Big Planet) could be a really cool feature to put in. If you entered the level editor you could draw any shape of background beams to play the game on. It was basic but it showed off the functionality we wanted and was testable. The game itself was written in Python, and we borrowed code from the open source games at www.pygame.org, in particular Balloons by Gonazlo Sanchez.

The second concept we prototyped was the T-Rex Prototype, named after T-Rex from Dinosaur Comics (whom we borrowed as our bad guy). In this prototype the player’s goal was to build the tallest tower possible while preventing T-Rex from destroying it by stomping on it (since hey, that’s what T-Rex does!). The player starred as a flying superhero who could pick up beams and place them in the middle, and could also punch out T-Rex temporarily. As you can see there are a lot of core similarities to the final game, as rudimentary as it was here!

After we had these prototypes we invited our friends over to test, and we got lots of good feedback. Here’s what we found:

Tree Prototype Pros:

• Showed the most early promise for intricate, beefy gameplay.
• Had lots of potential for replay value and interesting level design.

Tree Prototype Cons:

• Mechanics were very difficult to understand
• Lack of clear goals or constraints only added to confusion
• It wasn’t clear what the actual game mechanics would be, or how much design work it will take to discover them. Therefore it seemed very risky.

T-Rex Prototype Pros:

• This game provided a great “first five minutes” experience that people latched onto immediately.
• The narrative was compelling and hilarious, and lended itself well to all sorts of interesting gameplay ideas.

T-Rex Prototype Cons:

• Seemed to be in danger of becoming a complete twitch game, which wasn’t what we were going for.
• It wasn’t obvious how to build it into a community game, and there was no compelling case for a level editor or anything like that.

After talking about it a lot we decided that we would start on another prototype, one that would merge the good points of both prototypes. We liked the idea of fighting while building, and from this point onwards we made it a core principle of our game. We also decided we would make a more polished version of the game that we could potentially shop around to publishers if we needed to.

OK, that’s the end of our story for iteration 1! Tune in tomorrow to find out where we went next with iteration 2.

Don’t Eat the Mushroom… what can I say, the game is hilarious, unexpected, and a ton of fun to play. It’s guaranteed to be different from just about anything you’ve seen before, and if you’re anything like us you’ll be cracking up the whole way through. I don’t want to give away too much because of spoilers, but I will say that it’s probably ok to disregard the advice in the level title. Go give it a shot!

Most of the time the games we post on “What We’re Playing” are simple browser based games, and don’t require complicated setup. This one is a bit of a doozy, but trust me it’s worth it. First go and download and install Knytt Stories, which is pretty badass in its own right. Once it’s installed go and grab the user generated level Don’t Eat the Mushroom by Uncle Sporky. You might have to sign up to get on the forums, which also sucks. Once you’ve downloaded the level use the built in installer to pop it into Knytt Stories, and enjoy! There are several endings, so you might want to play through several times.

Of course, if you like it there are many other user made levels for Knytt Stories, but I’ve yet to find one as awesome as DETM.

There were a lot of announcements from this year’s E3 conference, including all sorts of fun, awesome games that I can’t wait to try out. It seems like the conference is getting back to something of its former glory after a few years of mediocrity. Even the booth babes were back!

However, the most exciting announcement by far (in my book) was that both Microsoft and Sony seem really dedicated to doing new, exciting things with user interfaces. Microsoft announced project Natal, which seems to be a camera that uses both the visible and IR spectrums to make some 3D guesses about where a user is and what they’re doing. I’m a bit dubious of the tech as there is no controller involved (what happens when users get tired?) and a straight up camera has other limitations based on the environment. However, Microsoft apparently has Johnny Won working on the project, which makes me feel a lot better. Let’s see what he can come up with.

Sony unveiled their own new tech with the PS3 Eye, and Rick Marks spoke about the advancements they had made with the tech since last year. They used a weird controller with glowing bulbs to help with camera tracking problems, and while this may seem less sexy than Natal I believe the controller will ultmately be more reliable as a result. It’ll also be nice to be able to push buttons on occasion if the user wants to. The Eye also has a microphone array so it can do voice detection – I assume the Natal does also but I haven’t seen anything about that yet. Rick’s a super smart guy (I got to chat with him last year at MIT) and I’ve got a lot of faith in his work too.

So will either, both, or neither of these controllers be successful? Time will tell.