Building Filbert Fledgling

How to Make Something from Nothing

By Randell Trulson

Growing up as a farm kid in the Midwest I had little or no exposure to technology other than a radio and a few electronic toys. I was always mesmerized by television, or any sort of video media. Unfortunately, the only time I was exposed to such things was when I would visit my friend’s house. The first time I played around with my friend’s VIC 20 I became obsessed with the notion of having a device do what it was programmed. A device that could have a limited ability to think for itself was too cool! I would sit down and stare into the slate grey pool of glass and watch it glow alive with artificial life. Making environments and objects from crude block characters and constructing worlds that previously were only in my head I found extremely compelling. The very idea that I could build an interactive piece of art, and be ruler over my creation was a powerful concept. It was then that I knew what I wanted to do with my life.

I started looking into what it would take to build games on a more serious scale. Unfortunately, the small farm-town library was not overflowing with that kind of knowledge. Several years later when we moved to Colorado where such technology was available I started pursuing it again. By then the power of the computer had matured, culminating into the Intel-based PC. Thankfully, my brother had the same interests and bought a Tandy 1000 (8088). Sixteen color graphics before EGA, 320 x 200 resolution and 256K of RAM! Technology surely couldn’t get more advanced.

Finally, I could start designing and building games as I had always wanted. It wasn’t long after when the realization sunk in that that games were far more complicated to build than to play. I found that building games takes a lot of knowledge in many different areas such as math, physics, art, and psychology in which I was severely lacking. If I wanted to be a serious game developer, I would have to start learning some of this stuff. I got quite frustrated with it all; where would I start? How much did I need to know? Did I really need Algebra? I really had no sense of direction. I just dove in head first with no sense of what to learn or why. I started learning bits and pieces here and there and trying to apply what I learned. It was definitely not my most productive time.

Getting Started

Completely hooked on the idea of building games for a living, my curiosity had grown into a passion. I wanted to build games even if there wasn’t much money involved. The pure creative outlet that it provided was reason enough. I was so excited to breathe life into the various ideas inside my head screaming to get out. The trouble was figuring out what and how much to know in order to build just one of my ideas instead of dabbling. At the time, there were no books on game development. I started by getting a general idea of programming and how games worked from magazines that had snippets of code in them. I would type the code in and try to get it to run. Inevitably, there was always a typo in the listing, causing me to learn how to debug the hard way. After getting the programs to run, I would start altering pieces here and there to see the results. My brother, heavy into programming, helped me understand some of the finer points. I don’t know that I would have ever understood any of it without his help. Soon afterwards, I started compiling and building executable code on my own in BASIC.

I found that in order to get my cool ideas to work the way I wanted, a lot of math would be involved. I faced the reality that if I wanted stuff to move around on the screen, I would need it. At the current math level I was at, my virtual actors, or sprites, on my virtual stage went on strike. After a long period of struggling with not wanting to learn math, I decided to bite the bullet and just push through it. Unfortunately this was after high school and I soon realized that I actually loved it, and that the reason I had hated it before was that previously hadn’t seen any real application for it. I look back, and regret the loss of time because of my stubbornness to learn. My advice is that if you have a mental block such as math, that is keeping you from making the games you want, there is only one way to get around it. Just do it and get it over with! I then attended a community college where I was properly taught plenty of math and other disciplines I would need.

After all the college courses in programming, math, and so on I decided it was time to really get down to business and build something for real this time. By now, there were many big ideas running around in my head, all fighting to get out. I was feeling very pressured to make something. Fearing the loss of time I had accumulated, I tried focusing on some of the biggest most exciting ideas first. This led to more frustration. I was a newbie and my ideas were not at a beginner’s level. In time, I accepted the fact that I had better start small and work my way up. Starting with projects that were more manageable, I worked on completing them first. Then I took what I knew, and began applying it to a bigger better idea. I started with simple text based games like tic-tac-toe, checkers, text based adventures, ESP detection programs and so on. This was hard for me to do, because I knew that these types of games would never amount to much. I knew that a developer’s first game was never going to be a block buster. Looking at the coolest games that were out, the developers had twenty titles or more before that big hit, most of which I had never heard of. This was very humbling and hard to swallow. It was then that I understood that making games was like martial arts; you don’t get your black belt after a month of classes no matter how hard you try.

Building the Foundation

I started out knowing nothing about video games, and with practice I had developed my ability quite a bit. I decided to try and get a job working in the game industry. I thought for sure this would solve all my problems since I wanted to make games for a living anyhow. This is where I ran into the next wall of frustration and a catch-22 situation. Game development companies wanted my name in the credits of one or more major titles, yet I had to work for one to get my name on a title. From company after company it was the same response, provided I received a response at all. Some told me to build a demo game, and my chances would be improved. I decided to take their advice and make a game demo. After putting a lot of time and effort into building a demo and acting as a twenty man development team, it dawned on me that I had enough expertise to do far more than create a demo. If I could build a demo, why stop there? Why not build an entire game? Furthermore, why would I need to work for a game company if I could do it all myself? After all, working for someone would mean that I would build what they want, not what I want. I decided that I could do this on my own. I knew it wouldn’t be easy, but it could be no harder than it had already been. Oh, how happy I was, and scared all at the same time.

This is where I came across my next trial. To build the games I wanted would be expensive due to the hardware, software, sweat equity, and knowledge that would be necessary. I needed money and not just a little bit. By this time I was a decent programmer overall, and got a job in the tech industry with ease. I was hired as a tester in the test lab at Symbios Logic, one of the biggest developers of SCSI adapters in the world. I started showing what I knew by building them some test software for their SCSI hardware. It was a small little program, but enough to get me out of the test lab and into an intern position as a developer in under two weeks! With time, I became a full time software engineer, and ended up learning tons about developing and releasing commercial software, teamwork, infrastructures, development cycles and other essential skills. I also was making a fair amount, and started saving as much money as possible for my own projects. In time I increased my pay by working for several different companies, each paying more than the one before. This is how I built up a nest egg to fund my own game development.

I took all the knowledge that I had gained over the years from working in the commercial software sector, and applied it to my personal game projects. Things like software life cycle designs, designing before programming, coding standards, standards for documenting, and development techniques that are bordering black arts. At this stage, I came face to face with the fact that I no longer building a video game. I was building a game company! I was going to need people if I wanted to build my big ideas. I took some of the money that I had earned and hired some lawyers to get everything turned into a legitimate company on paper. Thus Neuron Entertainment was born.

Where to Start

Taking what I knew from working on commercial software, the big idea games would have to wait with the lack of people and resources. I had seen how much it takes in time, people, money, hardware, and technology to make a bleeding edge project succeed. I knew then that you have to start small and grow. This concept was the most difficult for me to learn, but finally sank in. I started with a couple ideas that were games I wanted to build, but more realistic to finish. These were games in genres that had been built before, but could be improved upon. I pondered many different concepts, from ray-cast first person shooters to simple puzzle games. I decided I not only had to make something I could build and finish, it had to be in a niche genre where it wouldn’t get drowned out by forty other games in the same genre. If twenty first person shooters are coming out from developers that have funding, advertising, and an experienced team, the odds of being noticed are greatly decreased. I decided on the platform scroller genre, since it was accepted well on console systems, but had not been well done for the Intel based PC.

Now that I had a genre, I had to decide what the game would be about. Once again I selected an area that was virtually untouched in the PC market, the cutsie arcade style. Going back to my farm boy roots, I came up with the concept of Filbert Fledgling. Filbert is a baby Robin egg that is partially hatched and needs to get home for his remaining shell to be taken off by his mother. All this time I was continuing to work for the man, and was luring a friend, Dave Atkinson, who was originally my boss at Symbios, towards gaming. After the game’s design was finalized and it was time to start coding, we both quit our jobs and started working from home. This was by far one of the happiest moments of my life. It was also the scariest at the same time. I had left the security of a very well paying job, but was going to be doing what I had wanted to do all my life.

Dave and I had both worked several places together, and we both agreed on the standards and processes by which the game would be built. We designed everything in the game in advance, and determined what would be in the game and what would not, documented it, and stuck to the design. This was one of the biggest things I learned from industry that really saved us some time, plan everything out first! It is difficult to suppress the urge to take an idea in your head, and sit down and immediately start coding. Believe me, if you stop and write everything out that you want to do beforehand, you will see and solve all sorts of problems in advance that you never knew existed. Even if it is a mile high overview type flowchart, you will see issues, ideas, and things to look out for that you never would have thought about till they came up. I can’t stress this enough. The more planning you do on a project, the less debugging and hair pulling you will be doing when you are implementing it. Unfortunately many software companies don’t do this and find the big issues when the project is halfway done. Lack of planning is probably the number one reason for project cancellations, and slipping the schedule by such large amounts that your product is no longer profitable.

Before starting on the actual code and artwork for Filbert Fledgling, we sat down and decided who was more qualified to do each part. We did this based on past coding and engineering experiences, and a little on what each person would like to learn if neither of us had previous knowledge. Granted, for Filbert Fledgling we only had two people and a friend of mine, we had brought on board for music and sound FX. So delegating tasks was not the most difficult. However, we treated it as a critical part of the project since Dave and I had seen projects go down the tubes due to a lack of personnel management. So when implementing a project, know who is responsible for building what pieces, and in what order those pieces need to be built. Life will be much easier.

Implementation of Filbert Fledgling

The beginning of Filbert Fledgling was much the same as any project I had worked on in the past. There was a lot of excitement and energy surrounding the project, and getting it done. It almost seemed like everyone would just work really hard and the game would be completed in a week!

Then after a few months, and a few problems and intense debugging sessions, the momentum started to die down. Since Dave and I were not getting paid for any of the work directly, it was hard not to get bummed out at the amount of time it was taking to finish the game. This is where I learned that you have to keep the excitement level up, the momentum constant and make sure there is no bogging down. This was very difficult to do, especially when there was no certainty to the outcome of the game. I started to make milestones that had to be hit, not based on game structure or technology, but visual impact and excitement. This helped a lot. Every time we would hit a milestone, we had something physical to show for it and gloat about. This really put the wind back in our sails and helped us push through to the next milestone. I stopped looking at the game as a huge daunting project with an impossible amount of code and graphics, and started seeing it as a quest with several tasks or mini missions to complete. When looking at milestones instead of the end result, I suddenly noticed one day that the game was done! It was finally time to put it on a CD, and in a box. Using some of the money that we had saved, we paid for the production of game. It wasn’t until there was a sea of boxes all with my artwork on them and UPC codes that the reality finally hit me. We had built an entire video game from scratch all the way to production without anyone else’s help! The finality of the situation still has not hit me completely. It is one thing to work for someone and work on a project that is produced, but another to do it all from start to finish. It is a thousand times more rewarding.

Below is a list of items that I believe to be some of the more important problems to watch out for when developing a game. I am sure there are quite a few more, but these were the biggest ones for us:

1. Over ambitious schedules, and getting too anxious to get things done. My rule now is to consider how long you think it will take, double that and add twenty percent. That will be closer to reality.
2. Assuming the technology you are relying on works as advertised. I can’t count the number of times a piece of software, plug-in, API, or hardware that we were planning to use didn’t quite work as advertised, or was full of bugs.
3. Third party software problems, similar to #2. This is my opinion, but we now try to avoid third party code if possible. Several times, we got bogged down and had problems with third party software we were relying on. It’s difficult enough to debug your own game. It’s even harder to debug someone else’s technology along with it, all the time not knowing if it’s the game that is causing the problem or the third party code. To make matters worse, some of the third party developers are less than helpful. They are often slow to respond, or have gone out of business. We ended up ditching all third party code and found we could build our own, understand and debug it in far less time than ramping up on someone else’s technology.
4. Unforseen personal issues. I have yet to see a company take this into consideration. Odds are someone will get sick, a relative will die, your car will break down or a countless number of things that you can never possibly know about will happen. I found that it is best to just add some extra padding for it. That is how I came up with the twenty percent increase in schedule time.

Getting People to Know About the Game

During the development of the game, I knew that we had to get some press if people were to know about it. I looked into what it takes to get some game news posted on the internet gaming sites. I found publicity managers that offered to do this, but after seeing the prices they charge, decided that it was not a bargain. I didn’t think that it could be any more difficult than what we were already putting ourselves through to build the game, so I decided to do it. I started contacting these sites. The majority of all the major game sites ignored me, but we started getting posted on smaller sites that created some buzz. To makes things easier for me, I started a mailing list for press releases to track those that wanted to post news about the game. For the bigger gaming sites, we would pester them about signing up every single week, some of them for a year before they realized we weren’t going away. The point is that if you’re persistent, you will get their attention eventually.

While dealing with these gaming sites, I uncovered many pitfalls to watch out for. Some of them I found because I fell for them myself. You have to take into account that these sites have to pay a staff of people to keep them running, and are run like any other business. They don’t normally do anything unless it is in their best interest, regardless of how friendly they come across. If there is one major lesson I learned, it is to avoid giving anyone exclusive coverage because they are nice to you. When you’re small and starting out, it only hurts you in the end since your exposure becomes very limited. If a gaming site wants an exclusive, try to negotiate for something that will give you more exposure, like a banner add, or featured article that will last for a while.

Another method that we found to get some free attention was the local news. The newspapers and television stations quite often run into dry spells where they don’t have a lot of content. I was quite surprised at how quickly you can get some attention from local news sources. It is also cool because the locals will be supportive of what you are doing. Another added benefit of the local news is that people that you didn’t know existed find out about you, and help you out. The reason they didn’t help before was that they didn’t know about you.

The next method we used is word of mouth. Before Filbert Fledgling was released, we had a number of people that knew the game was coming out, and had told other people and so on. Soon we had built an entire network of people that we didn’t even know that wanted the game when it was released. From the word of mouth sales alone, we were able to cover our production costs of the game. This was very gratifying. This was also when the real excitement began since we were now starting to keep some money. Word of mouth is also good for the ego. There is nothing like having people that you don’t know playing your game and becoming addicted to it. We also printed posters and flyers, talked to local businesses, and implemented a wide variety of ideas to get the word out. Sure you might live in a small town, but you never know who in that town may have connections to the rest of the world.

Conclusion

As I stated earlier, I believe that video games are not so much products but pieces of art, and have to be looked at in much the same way. If you want to make video games, you should do it because you are passionate about doing it, not because of the rumors of millions of dollars that games supposedly bring in. Like any form of art, the more passion you have for it, the better you will do. With enough time, you will be rewarded for your efforts, but the real reward is the completion of the game itself! The fact that you made an entire virtual reality, an interactive piece of art that people can participate in, will make you quite satisfied. There is nothing that makes me happier than to watch kids play our game for hours and then throw a fit when they have to quit. That in itself is better than any monetary reward. If you want to make video games for a living, don’t get discouraged by what you read, hear, or see. If you are dedicated enough, and have a positive outlook from the beginning, you can do it. The hardest part about making games is just keeping focused on what you are doing. If you can do that, and get something out the door, you will be miles ahead of the rest. In time you will make more and more games that will get better and better. Soon after they will be on par with those released by the major manufacturers, except minus the fifty people in the credits. So the next time you see an article that tells you the days of the garage gamer are over you can skip it, and get back to doing what they all say you can’t.