New Adventures For A Developer

September 13th, 2010

Being an engineer has different aspects that are interesting once you get past the fact that we sit in front of a computer all day writing lines of code. One in particular that I’d like to talk about his the fact that we don’t necessarily do some work because we know how to do it, we do it because we know how to figure it out. Most programmers will write code for a number of different projects and different types of project for completely different purposes.

For me, one of the reasons working with RedPipe has been an interesting experience is our work for the film industry. It is an industry I didn’t really know that much about until I started getting into the ActZero office to understand the business and work on code while I watched them bustle around. It was fun learning the different rules and nuances of how they calculate how much everyone gets paid. It’s insanity really, to tell you the truth, but I wouldn’t expect much else from the group of lunatics that I love so much.

It was at the ActZero office that we came up with the name actually. We were sitting there trying to come up with a name and started spewing different ideas. Amusingly, there was a red plumbing pipe running along the ceiling of the office. It caught my eye and I just blurted out “red pipe.” It kind of rolled off the tongue so we went with it. Some people’s immediate reaction was that it sounded related to drugs, but I submit to you that anyone who thinks that might possibly be thinking about drugs more than they should.

There were other facets of utility development that I had to learn for the first time. Database development was something I hadn’t even glanced at during my four year degree at DigiPen. My mistake was researching the basic operations on a database, which I found very simple, without looking up overall designs for how a database should be laid out, which is where the real complexity of a database exists. I was able to make something that worked, but it was lacking in our ability to modify it.

Overall, I have certainly enjoyed jumping into new fields that I hadn’t learned about before. These are things that I can take with me for the future. I’m sure I will run across databases in the future and having that experience will be invaluable. The film stuff might not ever end up being that useful to me personally, but I had fun working with it regardless.

Posted in Uncategorized | No Comments »

Thoughts on Winter Wars, What Went Right?

August 2nd, 2010

We went into production with a team of three. Kiyome was our artist, Steve was our designer who also acted as producer in order to keep us on track, and I headed up all of the engineering. Weekly design sessions were used to keep the project flowing and make sure we were on track. Initial production was somewhat lagging, but I feel like this is just the danger of Indie development. There was a point, though, where we realized that if we don’t really ramp up production, we would miss the holiday season completely and that immediately sent us into high gear.

So we were going into the holiday season with a game way too big for us to finish. There were multiple weapons, purchasing of weapons, more enemies, and crazy effects. It would just be impossible to get all this done with the time we had left so we scrapped most of that. One weapon, three enemies, randomly generated levels. Cutting back to the basic essentials suddenly brought the nightmare schedule right into the realm of entirely possible.

It was this point in the production that I am really a fan of. We were a well oiled machine, with animations surging in from Kiyome and immediately going into the game for testing with our easy-to-use art pipeline. I had planned to get more engine features in, but with the time constraint, I was forced to make do with what I had. It made me realize that dropping tech for quick and dirty solutions can really be a perfectly valid way of doing things if there are time constraints. One major example of this is the day and night cycle. The entire project we had said that this would be impossible. We figured that we would need to create layers of each individual animation to blend between. What we ended doing was just having an overlay and a background to change the color of the entire scene. It worked out far better than we could hope and was relatively simple to implement.

Unfortunately, even though we were doing well getting things done, we missed the deadline for submissions that would make it for Christmas. In December of 2009, Apple decided to shut the iTunes developer connection down for a week before Christmas. This meant that anyone not submitted by this date would miss the holiday. Fortunately, because of the week-long shut down, anyone who submitted after this immediately went into review since the line had been emptied during the shut-down.

Our first submission was rejected by apple because of the use of private frameworks. If you ever find a solution for a problem online and they are using functions that you cannot find in the documentation, refrain from using them unless you don’t intend to submit this app to the iTunes store. Don’t worry too much about it though; if you are using private frameworks your compiler will most definitely warn you about it. I just chose to ignore it thinking it wasn’t such a big deal. After another submission, we were approved and released Winter Wars on January 1st, 2010.

I’d like to now make a few closing remarks about miscellaneous topics. This post mortem seems to shine the game in a negative light but in the end I think it has some enjoyable aspects to it. The game is mindless fun and you get to shoot some punk kids with lasers. The art and animations are a major strength of the game. Kiyome was really able to take our very silly ideas and turn them into characters and props that are fun to look at. I particularly like the young snowball thrower who runs away with his rear-end on fire when you shoot him. I, of course, also have to mention the ghost buster’s style laser beam, even though it doesn’t lend that well to gameplay, looks pretty sweet.

Another piece of the puzzle that fit together rather nicely was sound. We purchased a sound library since we knew we were going to need sound for a number of projects. After going through the entire thing, I picked out a few sounds that I liked and threw them in. For the music, I found a website offering free music and went through a number of different sections. After coming to a list of ambient tracks, I knew what I needed was something upbeat. I found one song that I thought was pretty good so I took the song and put it into a folder called “Pretty Good.” There were a number of songs that I thought fit decently so I put them in a separate folder. At the end of the browse, I found that only one song fit, and that was the one marked “Pretty Good.”

One last major thing that I learned from this project is just how slow Objective-C can really be. It is very easy to fall into the trap of memory allocations and deallocations everywhere. This is compounded by how slow even the simplest function call can be. There are ways of optimizing both of these situations, sometimes involving some dangerous hackery. What I would suggest is to write your heavy algorithms in Objective-C++ and if you really want to use Objective-C features, leverage its dynamic structure in gameplay programming.

Now that I’ve taken you through an indie group’s development of an iPhone game, I hope it’ll inspire some of you to go out and make something fun for yourselves. I can’t say I didn’t have a blast doing it. There were ups and downs throughout the project but that’s like any project. If you have any questions about iPhone development or just development questions in general, don’t hesitate to email us. We’d love to hear from you.

Posted in Uncategorized | No Comments »

Thoughts on Winter Wars, What Went Wrong?

June 13th, 2010

Winter Wars was the first game that RedPipe Media has completed. It leveraged an engine built in Objective-C over a period of a few months by me, our group’s only programmer. The group started in May of 2009 because I had just graduated from college and was looking for a way to keep my skills fresh. A friend of mine, Steve, suggested we go into iPhone development. It was a way to expand my toolbox so I made no objections and immediately picked up a couple of books and started learning.

As I was building the game engine, we brought on an artist, Kiyome, who I had worked with over the previous couple of years on school game projects, to help us start making prototypes.  Since she and I are both insane workaholics, we mesh extremely well together. There’s something for everyone to take from this. If you find someone who you work incredibly well with, that’s actually rarer than you’d think. Keep those people close since you never know when you might need someone with their skill.

One prototype stuck out to me and something that was going to be somewhat easy to make and could be kind of fun. In it, you fire a laser at snowballs scrolling across the screen. I was able to make the prototype in a few hours with my heavily content driven engine. I think our initial enthusiasm really stemmed more from the fact that I was able to make it so quickly, rather than whether or not we thought the game was actually going to be fun.

I personally was fascinated with the idea of firing lasers at things and snow is something that just made sense at the time with the approach of winter. I’m still fascinated with the idea of firing lasers at things, however designers beware: lasers that work like giant beams aren’t that fun in 2D. The issue is there is not a lot of skill development involved. You point at things and they explode. There’s hardly any room for error. It’s like taking a light gun game like Duck Hunt and putting the gun to the screen and shooting. The initial design was based on the roller coaster ride in Final Fantasy VII. You lose power on the laser as you fired it so tapping it was the best way to keep the charge. There were some things about this idea that we found more annoying that fun, so we refined it a bit.

Something happened at this point in the development cycle that I want to really emphasize as what NOT to do when developing a video game. We started building around the core gameplay after a simple prototype that we thought was ok. If you’re making a game, and you’re not totally constrained by a publisher, you have to know with every ounce of your being that your prototype is amazing and not just OK. The prototype is everything. The game built around it is just there to emphasize the prototype. It is your fallback if what you built around it isn’t that great. There is not a single thing in the development process more important than the prototype. It establishes what you’re setting out to do. We made the mistake of moving forward before our prototype was perfect, and we paid the price.

So you might be saying, “Well, this sounds like it turned out pretty bad if you were so unhappy with how it started,” but that’s where the bad ends really. There weren’t that many hiccups once we went into full production and I will go over that process in the next post. The take away here is heavy focus on the prototype is essential to make a good game.

Posted in Uncategorized | No Comments »

|

Recent applications