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.
 
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.