hot  /  reviews  /  videos  /  cblogs  /  qposts


Mijo Games's blog

8:21 PM on 12.09.2010

Road to IGF: 22 MB of RAM, Oh My!

Let me start that the moral of this story is one of the most oh-duh moments I have had as a designer yet. I am eager to jump to the punchline, deftly given away by my title, but let me start from the beginning.

I originally designed Duck Pond to be an evolving narrative, where as the player unlocked ducks, all previous ducks would stay on the screen. After all of the unlocks, the player would have seven fully grown ducks, capable of eating, swimming, and performing six individual tricks. For some reason, this seemed simple enough to me and would give the feeling of there being many options as far as who to feed. Also, the game was going to be essentially 2D from an art perspective, which means that we were going to use animated sprites. My vision was to have the movements of the duck be practically realistic, with a fluidity that pleased the eye.

My plans were humming along just fine until we get out first animated background. This background was multi-layered, with reeds blowing in the foreground and background, water lapping on the shore, movement on the surface of the pond. It looked great. We load it into the simulator and we start crashing. Turns out the art files are too massive, and when I say it, I mean it. RAM had not really figured into our calculations, and lets just say it should have. This background was over 500 MB of sprites. After some research, our programmer came back and told us that we had to fit each playable portion of the game: ducks, sounds, music, animations, into 22 MB of RAM. Yikes!

This was a total “no shit” moment for me. Mobile games do not look anywhere as good as other games because they have so little to work with. It really made me appreciate the elegance of some of the truly pretty looking games on the phone, and likewise, why there were not very many of them. There is no shortage of talented artists, there is a shortage of memory to hold that data in the phone.

Redesign time! Given the nature of my project, this new limitation put a lot of pressure on me to create something new but still use all of the parts that we had developed thus far. I didn’t want to tell the team to start over. In many ways though, this development was a complete blessing in disguise. As I had been testing and playing with the prototypes, it wasn’t clear to me exactly where the project was going: flicking was needlessly frustrating, activating tricks was difficult, and with all of the ducks on the screen, they had to be big to make tricks easier, which cluttered everything. Essentially, I did not love the game anymore, and that stung. My original vision of creating a zen experience, light on game-y-ness, had been lost somewhere along the way.

After some calculations, we realized that a lot had to change. We definitely had to drop our animation rate from 30 fps to somewhere around 12. No more moving background, at least not to the extent before. Additionally, we could not have more than two ducks on the screen at one time, and if we were lucky, we could have one or two tricks loaded in at any one time. We talked about swapping in and out animations and textures, but the team had had some bad past experiences with trying to do that. What could be less zen than glitchy ducks?

What I decided to do was take my game as designed and level it. What I mean is, if my first design was a tall building, where the player starts on the ground floor and works his way up to the 12th level, I took all 12 floors and put them on the ground. Instead of a linear progression, I split the game into chapters, chapters that broke up the experience into bite-sized chunks. Now the game is 12 chapters, each more-or-less accessible from the get-go. The narrative is still there, but it needs to be pieced together a bit more by the player. You watch ducks grow from chicks to full grown over a six month period, as the seasons change.

Most importantly about my redesign though was that it helped me focus again on my original vision. This smaller chapter experience allows the player to really just concentrate on feeding and watching the ducks, and not on trying to put bread in specific locations and unlock things. The first version I played of the redesign had me believing for the first time: I can really sell this. Sw33t!

Till next time...
Joe the CEO

For screens, news, and other details, check us out on Facebook or send us a mail at [email protected]   read

3:09 PM on 11.13.2010

Road to IGF: Take the Power Back!

After a bit, my team created a semi-working prototype of an early version of the game. It had most of the major features of Duck Pond implemented: there was a duck, on a pond, and the player can slide their finger through a zone of the screen to throw bread out to the duck. The duck could see the bread, swim over to it, and eat it. We even had the first trick programmed in, Groom. However, none of these features were finished; far from it, actually.

This is where I come back in. My programmer had designed the game so that many of the key variables of the game were all contained in one place. They variables included the size of the bread flicking zone, the movement speed of the ducks, the scaling factors for sprites to control perspective, etc.. Basically, any variable I wanted, he could create, thereby giving me, the designer, more control to craft the experience. Sweet.

A few notes about testing. First, if you are designing an App, you should have a Mac so you can run all the SDK, simulator, Xcode package and test your App. I had to upgrade mine to even run the latest operating system. Second, it also helps greatly to have a device to test on: iPhone or iPod touch preferably. Luckily, between my team we have most of the devices that may be running Duck Pond: iPod touch, 1st gen iPhone, 3G, 3GS, 4G, iPad, so we can test the game on each of these. One of the most common reasons an App does not pass certification for the store is that it crashes on at least one of the devices. The SDK comes with a simulator, but I found the best way to test it is the same way people will play it, on their devices.

The first, and biggest, task as the designer for Duck Pond is to make the bread flicking feel rewarding. We ran into a few problems early on. In the original version, players could flick bread in any which direction in the bread flicking zone. Essentially, the game was programmed to launch a piece of bread on a certain trajectory with a certain velocity matching the players flick line and speed. So, if the player quickly made a vertical line, the bread would fly out vertically with a decent amount of speed. Similarly, if the players made the same line, but horizontal, the bread would fly off to the side.

We quickly realized that having complete freedom to throw bread wherever was unnecessary and actually made the game more frustrating. Of course, when somebody goes to a duck pond, they can throw bread in any manner they would like, but this is a game, not real life. There is no point to allowing the player to throw bread way off of the screen. There had to be some balancing.

Another important issue had to deal with replicating flicks. Since the game would depend on the player being able to place bread in certain configurations around a duck to activate tricks, the player had to feel in control. Part of getting better at games is repetition, and when the player feels that they cannot even replicate the same actions, it becomes increasingly difficult. Imagine if in Super Mario Brothers, Mario’s jump height depended on how hard you pushed the button and the button was ultra sensitive - it would be no fun.

To tackle some of these issues, we implemented a new flicking system. First, we bound the angles that bread could be thrown out, essentially creating a cone shape of where bread can be flicked out. Then we broke this cone into ten degree lanes and told the game to round the player flick to the nearest ten degree lane so that the bread would come out more predictably. Lastly, we made the length the bread gets tossed proportional to the distance the finger draws on the screen instead of proportional to the speed and distance the finger draws on the screen. These improvements actually made the player feel more in control, despite the reduction in freedom. As with the other systems, we have variables to control each of these new functions including the overall number of degrees in the flicking cone, what degree to round each lane to, etc..

For me, this has been some of the most rewarding work done yet. It feels great to push your vision forward and watch some of the rudimentary aspects of the game be playable, improvable, iterated, and hopefully, completed. There are obviously many more examples of this type of stuff. I try not to stay too connected to any particular feature or function because you never know if it will work until you play it.

Till next time...
Joe the CEO

For screens, news, and other details, check us out on Facebook or send us a mail at [email protected]   read

8:25 PM on 11.04.2010

Road to IGF: Branding Like an Animal

If Mad Men has taught me anything, it is that Don Draper can get any woman in the world in less than five sentences.  Also, branding is important.  Your brand is how you want to present yourself to the world.  While it is easy to think of names, logos, etc.,  I found it to be a bit more elusive than just choosing the first thing that came to mind.  There were a few hurdles to clear before I found the proper brand. Perhaps an example will illustrate.

I originally wanted to call my company Yoga Dog Studios.  I took [email protected], signed my emails with the company name, began representing myself as such.  I wanted the logo while the game loads to be a short animation of my Boston Terrier stretching after he wakes up, first down dog, then up dog, freezing on his face.  Much to my chagrin, one of my interviewees began asking me about the website.  What website?  Turns out, there is already a Yoga Dog Studios.  I pop the name into Google, and wallah, there it is, a small production company in Colorado.  Their logo is a retriever-like dog striking down dog.   read

9:52 PM on 10.26.2010

Road to IGF: It Takes a Village

With the holy triumvirate of artist, designer, and programmer in place, I felt my company was off on the right foot.  The three of us got together and discussed where to start.  With the design doc finished, in many ways my job as a designer was put on hold while the programmer put the building blocks in place and the artist began generating assets.  I used this time to focus more on the managerial aspects of the company.  Namely, I wanted to grow the team.  My belief is that the more minds come together on a project like this, the better the overall product will be.

Rather than rattle off how I found each new member, I’d rather discuss some more general observations about the process.  First, the more you have done in terms of moving the project forward, i.e. hiring people, setting things up, etc., the easier it will be recruit others to your cause.  Every Joe Blow in the world has an App idea, but the more it looks like you are serious about executing it, the more people will take you seriously.  I found this to be especially true when reaching out to friends and family.

Another amazing resourc   read

2:35 AM on 10.21.2010

Road to IGF: Finding An Artist (or two, or three)

Once I had a programmer in place, it was time to find an artist.  One part of my company philosophy is that I want each major decision, including hiring key team members, to be by consensus, or at least, have each person weigh in.  When I began interviewing artists, I set up a tiered process to ensure that I found the best possible candidate.  Basically, I had two interviews instead of one - genius!  I set it up so that I met with the candidate first, then I had them submit a mock-up of a few screens or characters, and then I called the ones I liked back for a second interview with the programmer.  Of course, do not forget to have them sign an NDA.

Let me start off by saying that I had much more fun interviewing artists than programmers.    Along with resumes and cover letters, artist candidates have portfolios for you to review as well.  This was the first part of the process where you really get to see what kind of creative energy others will bring to your project.  As I said in an earlier post, I got more responses for the artist than for the programmer, so I had about 30 portfolios to go through.  One thing you   read

9:21 PM on 10.19.2010

Road to IGF: IGF...2011

Hello Destructoid.  We interrupt your regularly scheduled article series to bring a special announcement.  It is with a heavy heart that I inform you that we have officially missed the deadline to submit for IGF 2010.  I read articles that said that we could submit revisions after the October 18th deadline, but our game is in such a state at the moment, that it didn't make sense.   However, this has not discouraged us or our mission in the least.  In fact, the game has never looked better!

Setting this deadline and watching it pass provides a valuable lesson.  Things will not go as planned - bet on it : )  In some ways, we could see the finish line, but there were many obstacles, such as life, jobs, etc., that made it tough to get there in time.  All is not lost though.  IGF 2011, watch out!

We will now return to our regularly scheduled article series, tomorrow.

Till next time...
Joe the CEO

For screens, news, and other details, check us out on Facebook or send us a mail at info@mijo   read

3:20 PM on 10.15.2010

Road to IGF: Finding a Programmer, not in Belarus

After getting all of that pesky business stuff out of the way, I am ready to begin interviewing some programmers!  Woooo....oh wait, one more small piece of business...and this is absolutely the non-disclosure agreement (NDA).  Before interviewing anybody or even telling strangers your idea, have them sign an NDA.  This is a CYA measure.  This contract will basically give you legal recourse if someone steals your idea after you tell them about it.  If folks want a sample, hit me up at [email protected]  And, I’m just going to go ahead and say it one more time - do not depend on me or my sample NDA for legal protection or advice in any way, get your own attorney!  Just make sure whatever NDA you use, protects you thoroughly.

Ok, now we are ready to interview some peeps.  When I started putting my project together, many people who had worked in the software industry before told me about the various ways I could go about finding a programmer, most of them through the interweb.  Before that though, I reached out to anyone I knew personally who had any programming experience to see if they might be interest   read

4:10 PM on 10.07.2010

Road to IGF: What's My Game Again?

Ok, I decided to form a game company. Ok, ok. Yeah. Ok, wait, now what? Before I stormed Craigslist or Elance or whatever looking for workers, I needed a concrete idea. For the first few steps of the process, my vision was just about all I had. However, I believe that it was the clarity of my vision that attracted my talented team. For those trying to make a name, passion is more valuable than money.

My first task was refining my game idea into something that would actually be accomplishable. I thought about doing a traditional RPG or hack-n-slash but to compete with existing genres (meaning make some sort of clone with a few innovations) is a tough order when your (read: my) resources are extremely limited. I realized that I would never be able to stand toe-to-toe with the Square-Enix’s, EA’s, and Activision’s of the world, even on a mobile platform. I wanted something different. I mentioned in the last article that my idea is an App where the player feeds ducks. It sounded simple enough. There is one part of the screen where you flick bread out to the ducks that are swimming around on the rest of the screen. Ok, cool. But, how does it start? How does it end? What is the freakin’ point?

These questions will have to be answered by you for your game, but for me, I thought about what apps I would seek to emulate. Should I go down a social gaming route? How game-y should it be? I got feature ideas coming out my ears..oh man, where do I begin? I found answers and inspiration in the Pocket Pond app. Here was a “game” that people were buying that wasn’t so much of a game but a diversion. Like Flower, there didn’t really seem to be a point in the traditional video game sense. I like that. It is a new style of game. I saw opportunity for growth and diversity in this burgeoning area, which made it perfect for an indie like me. By branching out, I encountered the existential crisis of either this is a really cool innovative idea, or this is just plain stupid. According to folks I have told my idea to, some people think the former and others believe the latter. Get used to that.

I decided on creating a very casual experience, more of a diversion, but with a bit of narrative and a lot of cuteness. I settled on a trick system whereby ducks will perform tricks when the player places bread in certain positions around the duck. For example, if you throw a piece of bread on the duck, it will perform the Groom trick, and begin grooming itself. Tricks unlock more tricks, ducks, and eventually drive a small narrative about a family of ducks. Drawing off real ducks and their movements, I started thinking up ways to make the player go “Awww, how cute!” Ever mindful of my target audience (for me, families), I began crafting every part of my project: the company, the design, the art, to be marketed toward this audience. I believe this unification will be essential to any possibility of success.

Once I got an idea about the core mechanics, I began writing all of these ideas down. I recommend trying to visualize the basic layout of every major screen of the game. I also recommend giving yourself multiple sessions to do so. I worked for hours on my design thinking up each trick, how the bread flick should work, messages informing the player of unlocks and progress, etc., etc., only to realize the next time I sat down that an options menu would probably also help. Don’t be afraid of “Oh, duh” moments; they happen quite often. I ended making a separate section for Duck AI, the progression of the game, trick list, trick trees, player messages, and screenshots. One absolutely essential part of this design should be drawing screenshots. No single thing helped communicate my vision better than the (rather shameful, chicken-scratch) drawings I showed my team to explain the game. Finally, understand that the design doc is really just a blueprint. It is impossible to make all of the decisions before the game starts being made; I liken the process as similar to building a house: lots of decisions.

Cautionary note: for those who do not know, Feature Creep is a disease prevalent in all software development. It is the, “Oh, why don’t we have another button that does X, or we should add a feature that does Y....” The point of the design doc is to guard against feature creep. With limited budgets, feature creep can literally kill your project. I made it my credo to stick to the design doc as much as absolutely possible. Although I always encourage my team to bring me new ideas, my response to their often good ideas is, “I love it. Duck Pond 2.”

Getting my design doc in order was one of the best moves I have made yet. In many ways, it was the clarity of my vision (which creating the design doc definitely aided with the clarity) that allowed me to attract people to work with me. I can’t tell you how many people I interviewed who seemed happy to just be speaking with someone who knew something about games and knew what they wanted (even sort of). Putting those years of my life playing games that everyone told me was a huge waste of time to work, priceless!

Till next time...
Joe the CEO

For screens, news, and other details, check us out on Facebook or send us a mail at [email protected]   read

2:15 PM on 10.04.2010

Road to IGF: World 1-1

The idea for my video game came on the banks of the American River in Sacramento, 2007. I had recently received my iPhone as a gift for passing the bar and was discussing with my brother how it seems like just about every experience in the world was being made into a game. The relative ease of distribution and price of these new mobile games was opening up new frontiers of gaming. “See,” I said, pointing at a brown duck with little ducklings in tow, “look at those ducks. What if you made a game that was all about feeding ducks.” In the glow of this brilliant idea, the future seemed limitless.

Flash forward to May 2010. Due to the economy, I bounced from job to job, saving enough money to live through the times when I could not find gainful employment. I always thought that going to law school would be the “safe” path, but in these times, when it comes to jobs, there is no safe path. Demand keeps shrinking and wages keep falling lower. Facing the end of my most recent project, I realized I could keep reliving the same pattern, or, I could forge a new adventure.

I decided that I would rather pursue another passion of mine, video game design. I have studied the game industry my entire life as both an intellectual property attorney and a consumer, and it is true: Apple is revolutionizing the game industry for noobs like me. Fledgling companies now have the opportunity to test the waters with bite-sized experiences. I thought, if I can keep the game contained enough, then the project will be doable. As of now, I am sticking to that theory, but we never know what the future holds.

So, where is now, you may ask. It is September and my studio, Mijo Games, is up and running. I have hired a programmer, art director, three additional artists, a sound guy, a PR/marketing guy, and an additional designer, bringing the total team to 9. We are all currently hard at work on our first title, an iPhone app, Duck Pond. Our first major goal is to have a working version of the game by October 18th, the deadline to submit to the Independent Games Festival, hence the title of my series.

I am writing this column for many reasons. First, and most obviously, shameless self-promotion : ). Second, I have wanted to start a game company for a long time but I never knew where to start. I do not have a background in art, design, or programming, so there was no clear entry point. Hopefully, this series of articles will help anyone else who wants to try something like this get started. Additionally, I wanted to reach out to those who would be venturing forth on a shoe-string budget. They say the average App cost $30-50k to develop...lets just say, my budget is...mmm...less than that. Third, Destructoid is my gaming home - this community keeps my ears to the street for all things video game and I want to give back.

Moving forward, I plan on writing more articles dealing with the lessons I have learned about starting the company. Planned topics include refining a game idea, hiring programmers, hiring artists, suitable business methods, expanding the team, and corporate culture. These topics are flexible and will no doubt bleed into one another, and I hope that through these articles I can communicate how exciting it is to jump into the video game industry after so many years on the outside of the creative process.

For screens, news, and other details, check us out on Facebook or send us a mail at [email protected]

Joe the CEO   read

Back to Top

We follow moms on   Facebook  and   Twitter
  Light Theme      Dark Theme
Pssst. Konami Code + Enter!
You may remix stuff our site under creative commons w/@
- Destructoid means family. Living the dream, since 2006 -