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.
 
 Hello there this is Darren and I’m Team Helios awesome kismet scripters, even through the other members are too bashful to tell me face to face. As my first post to this blog I thought I should provide everyone with an Unreal Script developed for our game if anyone else in game design was looking for the same result.

In our game we have sections where objects fall and hurt the player when they make contact with them. So we need the actor to spawn in, destroy itself when it hurts the player, and have a life span long enough to reach the player from whatever height the object was spawning from. Aside from the static meshes uses many of the falling objects in our game extended off this one script and I hope it will help other game designers in their endeavors:

class FallingActor extends KActorSpawnable placeable;

var() int myDamage;
var() class<DamageType> myDamageType;

 event Bump(Actor Other, PrimitiveComponent OtherComp, Vector HitNormal)
{
       Super.Bump(Other,OtherComp,HitNormal);

       if(Pawn(Other)!=none && !Pawn(Other).bDeleteMe) //Is it a pawn?
      
{
            self.Destroy();
       }

       Pawn(Other).TakeDamage(myDamage, None, Other.Location, Other.Velocity, myDamageType,, Self);
}

event RanInTo(Actor other)
{
       Super.RanInto(Other);

       if(Pawn(Other)!=none && !Pawn(Other).bDeleteMe) //Is it a pawn?
       {
            self.Destroy();
       }

       Pawn(Other).TakeDamage(myDamage, None, Other.Location, Velocity, myDamageType,, Self);
}

defaultproperties
{
       Begin Object Name=StaticMeshComponent0
             StaticMesh=StaticMesh'PhysTest_Resources.RemadePhysBarrel'
              BlockNonZeroExtent=True
              BlockZeroExtent=True
              BlockActors=True
              CollideActors=True
              AlwaysCheckCollision=true
       End Object

       bWakeOnLevel
       bNoEncroachCheck=False
       LifeSpan= 5.0
      
       myDamage=10
       myDamage'DmgType_Crushed'
}

 
(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.
 
Picture
We will be approaching our official Alpha Build in a few weeks. We would love the gaming community, friends, and family to be involved with our development process as much as possible. We feel it is beneficial to the success of our game and to our success as Game Designers. Feel free to contact us regarding any questions, comments, or constructive feedback you may have regarding our game, Helios. We would also like to take this time to ask for your support in being beta testers for our game once our Alpha Build goes live! Contact us using the contact form listed in the Contact section or the various contact methods listed in the The Team section of this website to give us your information if you are interested in helping us make our game better! We will also give you credit as being beta testers in our final release! Spread the word and create some hype for us as we finish our game for the slated release date of January 31st 2013! See ya on the flip side!

 
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!
 
This week we took time to take a look at the big picture. We spent the beginning of the week looking at our milestones to make sure we were on track. We compiled all of the feedback we received from our professor and from fellow students and let that guide us this week. We did quite a few things this week and made some really big decisions.

First, we decided to revisit our mechanics to make sure that they are where we want them to be and to make sure that they synergize one another. We noticed that our mechanics, in fact, could use some more attention because they felt like they stood apart from one another too much. We decided to revisit our yellow and blue light mechanics and develop them more. We are working to make sure that all three of our main mechanics can be used in conjunction with one another. We also felt that revisiting them was extremely important for the development of the interactions in the game. We are really excited with where things are going with the game so far, and we are confident that all of the new changes will make our game much more immersive and engaging.

Second, we decided to look at improving performance for the game in the long run. We noticed that we were on track and even ahead of schedule with most of our milestones, so we looked into moving a lot of our kismet work into uscript. We feel this is a good idea simply because if we are successful, it will greatly improve performance in the long run, and if we fail, we will always have our kismet work to fall back on. We also felt this was a good idea considering the changes we are looking at implementing make our kismet work more involved possibly causing issues down the road.

Third, we decided to revisit our level design work and begin mocking up our first level. We all gave our feedback of some mock ideas and decided to break up into a level design team and a technical team for the remainder of the week. The greatest thing about our team is that we work together every step of the way and include everyone in every step of the development process. This was a great week taking us back to the drawing board in some sense and jumping forward to begin preparing for the delivery of our Alpha build. More news to come as the weeks progress!