Introduction

The purpose of this blog is to chronicle the development of our game using the UDK Engine and Blender. First and foremost: we are not experts, we are just two guys who happen to love gaming so much that we decided to try to make our own.

As of now (the format may change in the future), our posts will detail our progress (and lack thereof) in developing our game. This will include tutorials on how to accomplish tasks we’ve found to be especially daunting and random narratives about how we have encountered and overcome various issues in indie game development.

This first post will describe the steps for getting started in making your game, including: preparation, engine choice, and collaboration. In addition, I've given a narrative of the path we chose and explain the decision process that led to us following our specific path.

Step 1: Prepare (to be frustrated)

Making your own game sounds like fun, and it can be a very rewarding process, but you will undoubtedly run into plenty of frustrating issues along the way. Keep in mind that this is a learning process. Be prepared to run into unexplained issue after unexplained issue, followed by a visit to your friendly neighborhood Google for hours on end. If you run across a forum where a user answers your question with “you can’t do that,” keep searching, this answer is typically wrong. 

The smartest thing you can do is to plan ahead. Make a roadmap of short term and long term goals, decide what kind of game you want to make, and evaluate your resources. The Epic Games website actually has a good "getting started" overview, and I recommend using it.

Step 2: What’s Under the Hood?

Numerous factors go into trying to decide which game engine to use, or whether to use one at all. Without going into too much detail, a game engine provides a basic framework for a game; this saves time by keeping you from having to “reinvent the wheel.” Usually the engine already has features that you would otherwise have to program from scratch, like lighting and physics, incorporated into the system that you build on top of.

If you aren’t a coding expert, and don’t have an unlimited amount of time to spend coding your game from the ground up, then you probably want to consider using an engine. Some of the most popular engines are the Unreal Development Kit (“UDK”), CryEngine, and Unity.

There are probably more than a dozen different game engines out there, but not all of them are built alike. Some have better graphics than others, some are only for 2D games, some are free, and others are expensive. If you want to offer your game on multiple platforms, there are some engines that streamline the conversion process so that you (in theory) only have to code your game once. 

Because we didn’t have the time (and likely the coding expertise) to start from scratch, it was a no-brainer that we were going to be using an engine. When it came time to decide which engine to use, we evaluated our goals and resources. Here’s what we came up with:

• We had a total of two committed team members with some photoshop and coding skills (zero 3D modeling or animation skills present).
• Between the two of us, we had a medium amount of free time and basically no money to spend. 

I also took into account the fact that since both of us were brand new to the game building world it would make both of our lives much easier if we chose a popular engine with plenty of tutorials scattered across the net. UDK has indie friendly prices and hundreds of free tutorials available, so we went with that. If you choose a different engine, the rest of this blog probably won’t be very helpful to you beyond a possible entertainment value.

Step 3: Collaboration

When you have a team working on a software project, you need to have an efficient way for your team members to put their individual pieces of the puzzle together.  UDK has a third-party subscription service called “Perforce” integrated into the UDK installer, so that’s one option. I’ve also heard of people using services like Dropbox to collaborate (you’ll likely need to upgrade from a free Dropbox account, which is limited to two gigabytes of storage). In addition, there are numerous other collaboration services called “revision control systems” with acronyms like SCM’s and SVN’s.

My partner, Itsmyroad, had prior revision control system experience so he took the lead in choosing and setting up this service. Staying true to our budget of zero dollars, we chose the free options and decided to use Git with Bitbucket as our hosting service. To be clear, if you aren’t a distributed revision control guru, Git is the software on your computer that monitors changes in the folders you’re working on, and when you’re ready to share those changes with the group, it facilitates the process of sending those files out to be shared with the group. Bitbucket is the file hosting website (cloud storage) that stores all these files for your team members to download (using the Git software installed on their respective computers). This type of program is a great time saver because you only upload and download the files that were actually modified, as opposed to sharing the whole project with each update. Git also gives you the option to save your changes in different isolated “branches” so that you can share and test your latest changes in those separate branches without having to worry about corrupting your stable build located on the main branch.

Step 4: Get to Work

Now that you’ve made your roadmap, decided which engine you’re going to use (if any), and set up team collaboration, it’s finally time to begin working on the game. To make most efficient use of your time, each team member needs his own job (or jobs) unique from other team members. You don’t want four people working on level design, one guy coding, and nobody making 3D models. Make sure each team member has a job and a task to work on without having to wait for one member to finish before the next can start.

Itsmyroad was in charge of coding, and my job was to learn UDK and set up the initial game level. Our short term goal was to get some basic game features working using some rough 3D models. At this point, I began watching tutorials showing how the UDK works and how to use it. I was under the naïve impression that I could download and experiment with free 3D models from various websites without needing a 3D editor. I eagerly downloaded over a hundred random royalty-free 3D models, all in various file formats that (unbeknownst to me at the time) weren’t even compatible with UDK. When I finally sifted through, found, and imported a UDK-compatible 3D model, I was brought to the realization that most of these models weren’t built with an eye toward using them in video games. Even certain models labeled “game ready” still needed to be edited before they would be ready to be thrust into a video game. This is when I decided that it was time for me to switch gears and begin my journey into 3D modeling.

I already knew that Autodesk products would be out of my price range, so I installed Blender. Blender is a free, open-source program that is a pretty powerful alternative to the industry standard Autodesk products.  I played with the program some and followed numerous Youtube tutorials until I mastered the Blender basics. Within a few weeks I had progressed from making blocky models that were reminiscent of my Lego modeling days (I was not good with Legos) to creating a fairly realistic spaceship interior scene that I was actually proud to show off. Unfortunately, this elation did not last long because I faced issue after issue trying to import the model into UDK.

One of the benefits about working with UDK-- the vast amount of tutorials available--became one of the biggest hindrances. UDK has been around for a while, and certain aspects of the system have evolved over the years. I realized that I would now have to carefully screen every tutorial to make sure I wasn’t being fed obsolete information. I trusted nothing posted on Youtube earlier than 2010 and I was even suspicious of material more than a year old. Make sure that all your information is up to date so that you don’t waste precious time on an outdated method that may not even be compatible with your version of UDK.