The original Unreal Tournament game came out when I was in highschool and ate my free time like very few games before it. Seemed like at the time, at least within my group of friends, there were 3 big first person shooter games and you fell into either the Quake 3 Arena, Unreal Tournament or Counter-Strike camps. I didn’t have the patience for Counter-Strike and Quake was way to much of a twitch fest for me. Unreal tournament was just right though, and quickly became one of my favorite game series.

You can see then why I was so excited to see that Epic Games was rebooting the series, and even more excitingly that they were rebooting the series as community-made open development project with source code available to all. Originally I found this exciting because it’s a new way to make games that really hasn’t been tried before, at least not to this extent, but more recently I’ve fallen in love with this project because it’s an amazing resource for developers to see how a first person shooter like Unreal fits together — there’s only so much you can learn from searching Google. Sometimes you don’t know how to put certain ideas into words, but when you can go through functional examples of those ideas, everything suddenly makes so much sense. On top of the fantastic source code, the team behind the game hosts weekly twitch broadcasts where they explain why they do some of the things they do, and how they achieve certain functionality. It’s a golden resource for a developer like myself.

So I’d like to go over a few of the things I’ve learned about FPS game development by going through the Unreal Tournament source code. I realize some of these concepts are probably pretty rudimentary for some of the experienced developers out there but I found them useful, and I hope some of the other inexperienced devs can learn from these as well.

  1. Asset creation should be an iterative process.  With every weapon that the artists bring into the game, it seems incredibly important to them that they bring the unfinished asset into the game as soon as possible.  It’s impossible to see how an asset looks and feels until you bring it into the engine you’re working in.  I kept making the mistake of trying to get an asset finished before I tried to pull it into the engine. Part of the reason for this though was that at the time I was doing a lot of my work in Blender and the Blender to Unreal pipeline isn’t too simple right now, and the Unreal to Blender pipeline is simply a nightmare. I have to admit, though, this lesson has been extremely useful. You can’t block out an asset well without being able to see how it looks in game. Get your assets into game first and then go back and iterate on your initial design. Add detail, fix colors, hide parts of the mesh obscuring player view or make sure the model’s outline reads correctly from distance.
    Iterations on the Shock Rifle:
  2. There are 2 meshes for every weapon. This one makes sense but isn’t something I’d have ever thought about, but Unreal uses two separate meshes for every weapon in the game. The first is the standard low detail third person mesh that they use for pickups and to put in the hands of opposing players. You as the player never get close enough to the model to see that a lot of the little detail geometry does not exist on this model. The second mesh is the first-person version of the same mesh. It has all of the missing detail from the first version, but is missing the right side of the mesh and often the back as well. You as the player only ever only see one side of the mesh so you can save cycles by just not having another side of the mesh. It’s a smart idea, but I as a new developer would have never thought to do that.
    Bio-rifle from a third person perspective
    Bio-rifle from a third person perspective

    Bio Rifle from a first person perspective
    Bio Rifle from a first person perspective
  3. Use LODs heavily. This one I kinda knew beforehand but hadn’t realized just how heavily it’s used. The concept behind it is that from far away the player can only see so much of a model, so you use a low poly version of a model and then replace it with a higher definition model as the player gets closer. Unreal uses this pretty heavily and it’s interesting to really see what some of the models look like when they are far away. Edit: I just opened up the Unreal Tournament launcher after updating to get image examples and it seems all the LODs are gone except the default level? Not sure what going on but I’ll update this post once I figure it out. Unreal is making me a liar.
  4. Be open in your game development. Epic could not be much more open about how their development is going. The source code is available to all. I’m pretty sure that’s the best any dev could ever do, but on top of that, Epic is in constant communication with their gaming community between their forums and twitch streams. Even if you don’t feel like giving up your source code (a decision which probably wouldn’t make much sense for most developers), you can still take a huge lesson from Epic in how to communicate with your fan base. I’m pleasantly surprised by how much fan interaction seems to be steering the development of this game.

I’ll probably add to this list later as more things come to mind, but I’ve exceeded the amount of time I’m allowed to work on these things that my girlfriend gives me each week, ha ha. I hope some of these help.

 

 

 

One reply on “Unraveling Unreal Tournament”

Comments are closed.

%d bloggers like this: