The Current State of Modding

Modding has gone through a few iterations, waxing and waning over the years, and I have been having conversations with some steam friends about it over the past few weeks so I think I'll do a post about it, to get my ideas down on "paper". As usual, I'm just rambling here but I know some people take their scene history to heart so take it with a grain o salt. Also for the sake of understanding this article I would like to define four camps in the games development biosphere. The two in modding are the scene - the mod creators - and the community - the mod consumers. In "the industry" there is the indies and the AAA.

Ravaged Beta!

2Dawn finally did it!

Ravaged beta is here! Have a look! Everyone loves a good beta! Getting stuck in walls, no tutorials, crazy shit happening, it's great!

GET ON IT!

uTower - My UDK project

This isn't an announcement so much as it is a cave in of needing somewhere to post about this. I don't want to generate hype about it, but I feel the need to chronicle my progress somewhat.

uTower

Is the working name for the tower defense game I have been mulling over since about christmas-ish. You can read the concept doc here.

Blackford Stormington's Canine Pedestrial Assistolumundus!

Not enough time in the day to take your best friend for a rigorous constitutional? Stresses of ultra-modern life weighing you down? Overweight and lazy? Then look no further than the latest in Assistolumundus™ technology!

From the brains behind the Terry Toilsworth Tarry-no-more and the Automatronic Runcible Spoon comes the finest in modern lifestyle-augmentation design! A brand new approach to canine walking, the CPA ensures that old Rover gets the exercise he needs. With the newest Assistolumundus apparatus you'll find more hours in the day for your scholarly pursuits! The finest machining guarantees longevity of service and minimal parts-replacment, as you can see in the following demonstratory motion image reel:

Order yours today!

Blender to UDK: How I do it - Static Meshes

I have finally got a handle on making base-featured models. That is, a model with accurate collision and LOD data. When exporting from blender to UDK, you have a few options for format. I have been using the ASE exporter made by MCampagnini, one of the UDK community members, and up till today it had been going ok. My main issue with it was that the error messages were vague and unpredictable. In a fit of frustration today I decided to switch to the FBX exporter, which ships with blender 2.62. After a few hiccups here and there I found out how it works, and I gotta say I like it. However, it does have some very nearly fatal quirks for the uninitiated. Before I forget what they are, I thought I had better write them down.

Benchmarking Models

For a while I have been wondering how to find out just how resource-hungry any model is. Obviously the more details in a model the harder it will run the PC, but exactly how much, and what is the hungriest, is somewhat of a grey area for me. I was hoping that perhaps someone had made a program into which you could load a model and it would tell you how much cpu it takes to load, how much ram it requires, etc. Unfortunately it doesn't appear that this exists. This is understandable considering the different needs of engines, the different PC environments and I assume a whole range of other crap. But I still want to have something to benchmark my models against, dammit!

Ambiguous Package Name error in UDK and how to fix it

So I've been playing with UDK

and I came across a shit. After compiling my scripts UDK would pop up with an ambiguous package name error on startup. After some googling I found that this is because I had been making my scripts in a folder with the same name as the package I was working on. Seems like a pretty standard idea to me, name all your stuff the same, but UDK doesn't like that. So here's how to fix it.

Quaternions? I know, quaternions?

My good friend Weetbix gave me some stellar advice tonight on quaternions. I can feel the heat coming from my ears now. I'll let steam do the talking:

Black_Stormy: so I'm trying to code a new camera mode into UDK
Black_Stormy: and I'm using vectors and rotators
Black_Stormy: and doing math between them with variables that I have no idea what they are doing
Black_Stormy: in over my head or what
Black_Stormy: quote from a forum: Conceptually, I'm trying to rotate a stacticMesh actor so that it's orientation matches to a vector tangent to a spherical surface.
Black_Stormy: I know what thet means!

The difference between Source and UDK communities

As my legions of avid fans and readers may be aware, I have started to fiddle with UDK. A big part of working in an engine is the support you get from its community. For Source I have been predominantly lurking and sometimes posting on Interlopers.net and I have found the community to be open, honest and violently dedicated to mod/game dev. Since using UDK I have been lurking in the WIP section of the Epic Games forums. The community there is quite different.

UDK's inverted normal maps, and how to fix them

I have been modelling for UDK

For a little while now and I came across a hitch. The normal maps on my models were apparently inverted. This was odd because they looked fine in blender. As you can see in the picture, it looks like my bricks are concave, rather than convex.

The bricks are accepting light opposite to the direction from which it is being cast.

A short jaunt in google brought me to this thread. A bit of fiddling and I have found a workaround. The short version: invert the green channel of your normal map. The long version? Read on...

UDK or Source?

bear with me in this post folks, I have had a lot of chocolate

As you may have spotted

I'm a pretty entrenched source modder/modeler. I think I only did this because I saw some of the awesome stuff people were making on Interlopers and because I wanted to make models and maps for L4D when it was booming. That and the fact that the SDK was free pretty much tipped my hand.

I have worked with other engines briefly in my earlier days when I was modeling really bad models for really bad games being made by really bad dev teams. One project took me through 3D Game Studio (HORRIBLE), Torque3D (AWESOME) and a few others I forgot about. Recently I have also worked with Wolfire's phoenix engine which was awesome and I plan on using it exclusively if they release it.

This week I decided to try out the UDK after seeing all the pretty screenshots people have managed to get out of it, and after hammer and studiomdl.exe combined forces to send me into an uncontrollable fit of rage. Well folks, god damn. God. Damn. I can't even think of a witty caption to describe just how much more I like UDK. Just to be clear, Hammer hates me and the feeling is mutual. Every time I try to learn how to use hammer, I come out the other side with blood pressure like a hyperbaric chamber and a desire to defenestrate my monitor. We do not get along.

The UDK map editor, however,

Made me want to explore it. I watched some tutorials (which were a: easy to find, b: mostly up to date and c: maintained by the developers of the engine. All features you won't find in valves documentation. And don't VDC me, the VDC is about as understandable as the poo smears of a demented monkey on smack.) and I immediately started to make a map that looked nicer than anything I ever created in source.

I also decided to make a model to see how the blender pipeline would work.

Just to put this in perspective, it took me somewhere between a week and ten days to get my first model into source. Granted I was pretty new to engine modding then, but this model took me about an hour. The learning curve was so slight solid helium would hardly slide down it. The material editor is nothing short of awesome, considering I used to use MapZone for textures and blenders node compositor, the layout was easy to grasp, albeit the node names are kinda wierd.

Drag and drop!

I think it was about the late nineties when drag and drop became the norm for interface accessibility. Source SDK has **no** drag and drop. Everything is imported and exported using backdoor and commandline tools that may or may not break your asset, mod or even themselves if you aren't the dude who programmed them. UDK is just drag-and-drop-a-licious.

So anyway enough gushing, I could hate on source all day, hell I have spent the last two years hating on source, but it won't get me anywhere. In my dream of being an indie art developer, modding has very little chance of turning a profit. Mods were a good stepping stone to help me learn how models need to be made for actual games, but I think I'm ready to kick that rock over and jump in the mud now. I'm moving to UDK, fuck source.