Into the Unknown: UDK Part 4

I’ve finally reached that breaking point where I am comfortable with the Unreal Engine. I may not have knowledge of every aspect, but I am finally understanding the basic axioms driving the inner workings, which allows me to intuitively understand where to look when I am stumped. The unfixable problems are falling away as my problem-solving abilities increase with respect to the environment. When you are utterly clueless about the engine, it can be difficult to know what kind of help to look for.

So in the past few weeks I began working on the project again. This time, I would build up an easy, lightweight framework from the UDK (rather than UT) packages — that is, I started out with much less pre-built functionality so that I could understand everything that was going on.

I succeeded. So far I’ve built a basic Pawn framework (Pawns are objects controlled by players or AI) with a custom crouch system and an Inventory Manager that better suits my needs. I’m also working on a Weapon system, although I haven’t implemented sounds, particle effects, etc. My HUD system is minimal, but so far that is all I need.

When I need to, I go to the UT packages and look at their implementations. However, the number of times I’ve copied and cut down code has decreased dramatically. Now I can write my own code with confidence that it does everything I want it to (note that although I am perfectly comfortable coding, it is more about knowing which function calls go where in the logic chain, and what to reference).

Note that I don’t have grenades, vehicles, sounds, shields, AI, other characters, or environments yet. However, I’m more comfortable having a small, solid base of functionality that I completely understand, rather than a thin spread of half-implemented, opaque features. Down one road lies abandonment, down the other lies slow but steady plodding to completion.


Into the Unknown: UDK Part 3

My exploration has continued to go off the expected tracks. For some unearthly reason I decided that my first goal would be to port a character model from Halo to the UDK. Well, I’ve learned a lot through my experimentation. The first thing, of course, is to get the model. I downloaded a low-poly model of the Halo 3 version of the Master Chief from Halomaps. The great thing about downloading a tagset for Halo: Custom Edition is that the model comes with a bitmap. A lot of the 3D models on that site are better quality, but lack textures.

Easy-Bake MC (broken image)

So, using conversion utilities also downloaded from Halomaps, I converted from the Gearbox formats to 3DS and TARGA formats for models and bitmaps respectively. The models come pre-skinned, so all I have to do is load in the texture. Of course, I also have to do any rigging I need. Thus, I re-learned rigging in 3dsMax this week. Strangely enough, the vocabularly is ambiguous when it comes to this process. To my knowledge, rigging refers to either the creation of the skeleton OR the application of vertex weighting to a mesh. Similarly, skinning can mean vertex weighting OR texturing. Very strange.

I used one of the skeletons that Epic provides, because it means that you can use the animation sets already in the UDK. I got my Master Chief model in-game finally. There is a lot of boilerplate scripting that goes into creating a new player-character. I also had to fix an (apparanetly prevalent) issue in which any character model (even the examples that Epic provided) would float above the ground. According to online forums, all I had to do was move the origin of the mesh down. Well, little did I know that there are actually two “origins” to a skeletal mesh. One is for the bounding box, and one is for the mesh. It took me a good hour to figure out that I was changing the wrong origin.

Ingame MC! (broken image)

Then I moved onto creating a weapon because the MC I imported looked absolutely swell (except for a few errors in the rigging). I found a great tutorial that explains all the steps, and introduces a way of animating the first-person arms separate from the weapons, and then combining the two meshes using scripts. That way you can change the model of the arms or the weapon independently from each other, and don’t have to re-import the first-person arms for each new weapon. The weapon (a MA5C assault rifle) was breeze to rig and import ingame. The arms were a bit more a struggle.

It took me a little while to realize that I don’t have to use the first-person skeleton provided by Epic, because I’m not going to be using any of their animations. By that time, I had already skinned the arms to their skeleton, though. Because of weird transform issues with 3dsMax’s skinning, I kept getting this seemingly-unfixable error when I imported the arms:

FUBAR Arms (broken image)

It didn’t help that the tutorial I was watching used ActorX to export animations rather than FBX. Well, I realized that instead of trying to fix this utter mess (into which I had poured hours of work), I should just hop over to Halomaps and grab a pre-rigged, pre-textured, ready-to-go set of first-person arms. And that’s where I am right now.

Into the Unknown: UDK Part 2

Well, it’s been a while since Part 1. The delay was a combination of final exams and my re-discovery of Unity (the game engine, not the Ubuntu UI – or the Linux distribution for that matter). But I’ve done a little bit of tutorialing, and so far I’ve learned to set up a new gametype, and have been practicing BSP creation. Unfortunately, I’m using my second monitor for the computer I built, so using the Content Browser or reading a tutorial while working is very annoying.

Honestly, the BSP system is slightly vexing. I don’t understand why I have to use the template shape to add and subtract geometry. It would be much easier to create brushes like in the Source SDK, and then apply the boolean modifiers to them. Shapes without modifiers would just be ignored. The visual scaling in the Source SDK is much easier than entering values in the UDK. Another very minor detail is the fact that you can’t use negative wall widths in the UDK. In the Source SDK, negative values indicate an outward expansion, leaving the original volume an empty space. In the UDK, however, it just places the subtraction volume outside of the addition volume, or some other strange behavior, which results in a very strange visual result.

That’s all I have for now. The next step I imagine would be learning to create materials. I have already done this in my previous explorations, but I need to figure out the editor in more depth. I’ll be in California for the next 10 weeks, but I’ll be able to work on my laptop.

Into the Unknown: UDK Part 1

I tried this before, but ended up quitting. I believe now that my exit was premature. I refer of course to my adventure into the Unreal Development Kit, a free version of the Unreal Engine that allows developers to create their own games in the Unreal Engine.

My reason for embarking on the adventure was to recreate the gameplay from Halo: Combat Evolved on an updated platform. The bonus is two-fold. For the longest time, I have had a Halo custom campaign in the works, but have never really gotten the Halo Editing Kit tools to work for me. Secondly, I have always felt the need to learn how to use a 3D game development tool. After exploring Unity slightly and having dabbled in CryEngine 2 (and somewhat 3), I decided it would be good to experience the Unreal Engine.

Posting updates on this blog serves two purposes: One, it keeps me from giving up again. Second, it helps me quantify my successes and organize my thoughts. Hopefully I can post an update on this project every two or three weeks, with either video or pictures to show off new milestones.

Without further ado, I want to outline some of my goals for the upcoming project:

  1. Learn how to create:
    • particle effects
    • weapons
    • vehicles
    • characters
    • AI behavior
    • scenery
    • level geometry
  2. Learn what else I need to learn
%d bloggers like this: