Changing the game icon in UDK is a surprisingly simple but cool thing you can do to give your game a little more personality.

First of all, you're going to need an image in either .png or .jpg format.  Make it perfectly square, and make sure it'll look good at various sizes, as Windows will make it bigger and smaller depending on whether it's in your taskbar, start menu, or file hierarchy.

Next, take that image to ConvertIcon.com.  Upload it and then export it as a .ico file.

Note: .ico files have pages which store various sizes of the install icon for various uses.  Download your .ico from ConvertIcon in all of the sizes offered and you'll be sure that your game will stand out no matter where it's installed.

Now go into your UDK hierarchy.  You're looking for:

C:\UDK\UDK-2012-07\Binaries\InstallData

In here you'll find a .ico file called GameIcon.  Reserve it someplace else in case you want it back later, and replace it with the one you just made with ConvertIcon, making sure to rename it "GameIcon"

When you cook your game, the UDKInstall will still have the same icon it has always had, but when the game is installed on the hard drive, it will have whatever logo you dropped in there.

Download and install Helios to check out our cool custom icon!
 
This is another swing at the low-poly visual style I tried for in my last test.  This one's a lot better-looking and includes actual Helios gameplay (though slightly dated).  Take a look:
This level was done using Level Streaming for the Nature and Mechanical worlds, meaning we streamed in all of the assets, sounds, volumes, and Kismet required for one world while streaming out those required for the other world.

The level-streaming system is remarkably convenient in terms of world-building, because anything we wanted to exist only in one world, including otherwise difficult things like Post Process Volumes and sound effects, we only needed to put in one world.  However, when cooked into an executable there's a jarring lag when streaming levels, so we had to find another solution.
 
To create a custom sprite actor for use in UDK, you'll first need to import a texture to UDK, so we'll do this in two parts, one for setting up a texture, and one for attaching that texture to a custom actor script.

1.) Importing a Texture to UDK

To import a texture to UDK, you'll first need an image.  This image will have two very specific requirements:

1.) It must be in the windows .bmp file format.
2.) It must be a perfectly square image, with dimensions in powers of 2, like 1024 x 1024 or 512 x 512.

UDK will not allow you to even try to import a texture if it does not conform to these two criteria.

You can create your own image in image software like GIMP, or find something using Google (try the "Exactly..." filter in the size section on the left of Google Image search to refine your results to images that fit your size requirements).

Make sure your image has transparency.  If not, you'll have an awkward-looking square picture with a background.

Make sure the image is saved as a .bmp.  I did this for my custom sprites by opening the .jpgs in GIMP and clicking Export and saving them as .bmps.

In UDK, open your content browser and click "Import", then select your image and give it the appropriate package, grouping, and title.  Once you've completed this step, you should have a brand-new, usable texture in UDK.

Keep UDK open for a minute, and we'll get into the script.

2.) Creating a Sprite Actor in Script

In whatever script-editing software you use (I use Microsoft VisualStudio with NFringe; it plays nice with UDK), create a new script in your custom scripts package.

Here's what you'll need in the body of your script:

class MyCustomSprite extends Actor
   placeable;

defaultproperties
{
  begin Object Name=YourSprite
    Sprite= // Sprite's Full Name Goes here
    HiddenGame=false
    AlwaysLoadOnClient=False
    AlwaysLoadOnServer=False
  end Object
  Components.Add(YourSprite)
}


Go to UDK and find your texture in the content browser, right click on it and find the option "Copy Full Name to Clipboard" and insert it into the relevant space in the script, after "Sprite=".

That's it.

Save your scripts, close UDK and reopen it to rebuild your scripts, and you can find your sprite in the "Uncategorized" section of the Actor Classes tab in your Content Browser.
 
(This is a simple guide I made for the team for importing new fonts to use in the UDK.  Unless you're making a game based on Star Trek or the Aliens franchise, UDK doesn't have a lot to offer you in terms of fonts.  Here's a quick and easy guide to getting new fonts into your projects.)

To import a new font into UDK, it must first be accessible through your system's control panel.

In order to do this, download a font (Dafont.com is a great resource for amazing, free fonts).  Double click the font to open a preview, and click "install font."
Picture
The font preview screen in Windows7
Now head to UDK's Content Browser.  Find the package you want to import to, right click in some blank space, and click "New Font."  Fill out the dialogue with all of the necessary information (Package, Grouping, Name) and then, at the bottom, click "Choose Font"
Picture
Make sure to fill in your package and grouping, name your font, and then select "Choose Font"
In this pretty familiar-looking font window, you'll want to adjust the size of the font.  Whatever size you import it in will be its default rendering size, so pick a size that's comfortable but that you can still fiddle with.  I chose 22 or 24 for all of the fonts I've imported so far, but smaller or larger is fine.

When you're done, the font should be imported properly to the UDK, and can be used in any rendering scripts you use for putting information on the HUD.
 
I started out the week by crafting this little NPC interaction prototype:

The NPC interaction is all done in Kismet.  A trigger starts the animations on the skeletal mesh in Matinee, and simultaneously renders the text to the HUD.  Setting Activate Delays helps disable the trigger until the animation completes, and the text goes away.  The "..." that indicates the NPC is ready to talk is a simple texture I made in GIMP and applied to a script cleverly called "Helios_DotDotDotSprite," and is pretty much identical to the sprites I made in my visual style test.

Next, I put together the website!  This was a ton of fun.  Using Weebly, our videos, and images created by the team and found on Google, I snapped the official Team Helios Dev Blog site together, and I'm pretty happy with the result.  It's still coming together, but aside from persistent content like trailers, blogs, and builds of the game, I'd call it about 85% done.

My third task this week was designing Level 2 of our game.  This was a bit of a process.

First, I doodled out the levels on a sketchpad and took pictures of them with my iPhone.  We designed each of our ten levels in three short chunks, which serve as both places at which to stream levels and to provide the player a checkpoint. 

Here's my early mock of 2-A, for your viewing pleasure.
I decided I was pretty pleased with this for about 8 hours, then decided I absolutely hated it, and needed to take another go.  I noticed my own reluctance to engage the Nature World (see how it's just a little sub-drawing at the top?) and decided that had to change.  I assembled Version 2 using Google Docs' Presentation format, breaking the level up by "puzzles" or "rooms" and going into a lot more detail as I went.

Here's an example from the first "room" of Level 2-B:
This is further evidence of my preference for Microsoft PowerPoint as image-editting software.  The modularity and layering of the images is really helpful for finagling little bits and pieces to help get the message across.

The team looked this over and preferred this format and this version of the level.  Much of the design was redone for version 2, which includes a cool ending minigame that almost subs for a boss battle, NPCs with dialogue, and a much better series of challenges than the original version.

I also discovered my ideal work environment: I sat down at my desk with a glass of Sangria and "Nobuo Uematsu Radio" playing on Pandora, and cranked out that whole level design.  Rock on!
 
I created this simple test in UDK for a unique, easy-to-produce, vintage style.  I developed the look inspired in part by voxel-based games like Minecraft, Cube World, or 3D Dot Game Heroes, and in part by collage-style games like And Yet It Moves or Tearaway.

The benefits of this style are improved engine performance, ease of creation and decoration, and unified feel across diverse level designs.  The Helios team doesn’t have much in terms of 3D artists, so I tried to come up with a style that would allow us to create and use our own assets without having to shape anything, but still allow us to have a look that was different from the standard Sci-Fi-heavy asset packages bundled in with the UDK.  Using N64/PSone-era imagery combined with the UDK’s ability to render beautiful depth and lighting seemed like an interesting experiment, so I gave it a shot.

The foreground actors that the player jumps on have very simple collision, but all of the other actors have none.  Every cube in the scene is the same mesh rendered at the same size, though materials vary.  The platform is the same cube, but rendered at different proportions than the others.

Leaves and grass are sprites generated from a simple texture file. The code used to create 2D sprites (the leaves and grass) is found here.  This code will require some adjustment, as the sprites created from this unmodified script will flicker in and out if their origin is obscured.  Hint: check out the standard Trigger actor’s defaultproperties, because it doesn’t suffer from the same blinking problem.

The background sky is just a big plane with a cloudy material and a panner node plugged in to give it a gentle, breezy motion.

I assembled the simple level in very short time using only materials found on the internet with Google image search, sometimes modifying them in GIMP.  To simplify my process, I searched for textures that were already proportioned to exactly 1024×1024.  This is because the UDK has some simple rules that must be obeyed for texture importing:

  1. Image must be perfectly square
  2. Image’s dimensions must be powers of two (32, 64, 128, 256, 512, and so on)
  3. Images must be in .bmp format
The mellow chiptune playing in the background is “Yellow Dust” by Rolemusic, and was found using the Free Music Archive.  Importing music into the UDK requires some finagling as well: you must upload only .wav files.  To change any music file into a .wav using only iTunes, check out this Apple tutorial.