.iveytron.

Climbing Out of the Hole I've Been In

2012-03-03T19:48:00.006-08:00

Hey all, it’s been a good while since I have last blogged, and there’s a perfectly good explanation for that!

First off, if you look, over the past 6 months, I have posted a good bit of my work from Full Sail. The last post was the last thing worth posting in Game Design 2. I’ll spare you the details of my experience in the course, but I will say that it was incredibly unpleasant, and I have nothing to show for it at this point.

Last month was a non-game-centric class, Interpersonal Communications, and I know you guys would probably appreciate NOT seeing those assignments up, though I do admit, it was a good class, and I did fairly well (100).

Another large thing that has happened in the past month is a job change. I took a position as an iOS developer here in town at a startup as my new job, so as of March 12, I am no longer just an independent developer, I’m finally legit! Once more details are allowed to be shared, share I will.

Currently, March is a two-class month for me, Aesthetics and Immersion, and Project Management and Assessment. The first requires much documentation and GameMaker work, and the second is a fully loaded, DIY UDK class, so It’ll yield some content to upload, hopefully!

So, apologies for the excuses and lack of cool things happening, but you’ll be seeing some more UDK work up here in the next couple of weeks. Take care y’all,

-ivey

Game Design 2 - Week 1 Assignment

2012-01-13T06:18:00.002-08:00

This past week, we were tasked to create a new game idea and a "poster" outlining its interactions, mechanics, a flowchart of the mechanics, and a quick mock of what a game the game would look like, etc. After spending the evening in Waco with my tattoo artist, I decided to pick her brain on some of the challenges that people in her job face when working on tattoos, and how their skills progresses with experience.

As most games that try and emulate a real-life skill (guitar hero, for example), most of the physical "work" is represented in a manner that a player can grasp without having to learn the job itself. I had to water down her real life interactions and translate them to a screen with controls in a manner that would be appealing for a player, while keeping the Macro and Micro goals similar.

On the large goal side of the spectrum of play, the player is to build up Reputation and increase their abilities throughout the game. On the micro-goals end, the player will be working through each piece trying to do a good job in a timely manner.

So, I present to you - Ink Shop. Hope you dig!

Click Here for the full size image

Prototyping 2 - December 2011

2012-01-10T06:01:00.001-08:00

So this post is like, super late... I'd blame the holidays and traveling and all that pizzazz, but c'mon, we all know that I've been marathonning Skyrim since it dropped. Am I forgiven? Please?

Ok, to business -

In Prototyping 2, we were tasked with creating a brand new game in UDK. The only stipulation, however, is that it could not be in first person. Our team happened to be the same guys that worked on the Level Design 2 project, so we were fairly comfortable with each- others skill set and familiar with how we all worked. Starting the project was incredibly easy going, and we got ahead quickly.

After a night of long discussions on what we should make, we voiced our ideas to the teacher in a Skype session and decided that one was better than the others. This idea, however, had no player token, as it was a Pinball offshoot; two things that we as a class had not been exposed to. The game was to be a Pinball style game in play, but we wanted to implement a defense mechanic by having bots raid the gutter. Our main question with the prototype was "Can we make a Pinball game with Tower Defense elements and combat that is enjoyable to play?"

Questing to make a pinball game in UDK leaves the creator with many obstacles to tackle, as it is entirely different than the standard Unreal game. Here are a few tasks we had to implement (Far from exhaustive, but some of the more important things)

Make realistic rolling ball
Decide on whether to use a tilted board or gravity volumes to emulate the table
Remove player token
Set up stationary camera
Tune flipper and ball locations / velocities
Implement a scoring system
Kill Z volumes for bots and ball
Create a HUD to display player and enemy score.

We created the ball as any normal human would: an Actor Factory, spawning a kActor. The ball was fairly simple to get rolling correctly, as the toolkit added a collision model called Sphere Simplified Collision (the pink lines on the image), so we used that model for our ball.

This makes spheres move like they should when rolling on a plane without having to calculate all the little bends that a normal collision model would have. The big trade-off here was that I couldn't get the ball to collide with Pawns when it was being used. This frustrated me immensely, and i had to made the decision whether to sacrifice the ball movement or work around the issue. In pinball, predicting the how the ball will behave is crucial to the game play experience, so I knew that was not an option. I'd have to find a better way.

That better way came in the means of me making a trigger that i would attach to the center of the ball that could interact with Pawns. This way, i could do events off the trigger instead of the ball kActor and not sacrifice the most important part of the game. I just had to attach it to the spawned ball object, detach it when the ball was destroyed, and reattach it to the next spawned ball.

For the gravity, we felt it necessary to use volumes instead of tilting, as tilting would effect everything inside the game, including the AI Pawns we were spawning for destruction. A small bit of tuning later, and the ball moved like a champ.

To remove the player token, we decided to just "fake it" instead of editing out new game type we created. Since we had little time to accomplish this project, this worked out well. And, hey, it's a prototype, right? ;)

The Camera was also really easy to do in Kismet. Once again, would have been better to include this in the new game type we had created, however, time was of the essence, so we made do.

The flippers and ball velocities took some time to tune. After a good bit of play with the prototype, they came out fairly well. One of our groupmates spent a good bit of time working exclusively on the feel of the game board, and it was excellent.

The scoring system was as easy as adding to some named int variables upon events. Pretty self explanatory stuff. We added new kismet nodes to look at those ints for HUD use later.

The KillZ volume was put in place to destroy the ball when it hit the gutter. We had to be careful with the bot paths to ensure they did not accidentally end up reaching it before they scored, or they'd just be destroyed.

Last big deal was making the HUD. One member of our group handed this all on his own, which included making the special game type and tying the variables to it.

After a bit of tuning, the game came out decently enjoyable. We proved our concept and answered all of our design questions. The prototype was a success by the time we reached the last week, so we took advantage of the free time and added new bumpers, explosion effects, and even an easter egg for when the player is losing badly.

Heres a short vid of the game in action

We had a simple idea, and an incredibly manageable about of work throughout the month. I am pleased with the outcome, and so was the instructor.

Last Weeks Assignment for Prototyping 1

2011-11-17T19:06:00.000-08:00

So i just turned in the last assignment for Prototyping 1. This one was remarkably less involved than the rest, as we just had to create a custom game type that took the player out of the first person perspective. Making this work requires 3 new classes: A new Game Type, a new Pawn, and a new PlayerController.

I decided to do mine by changing the Mastermind game from last week to have a Gears of War style view so the player could see the guessing grid better, so here is what i did.

Using the UDN examples of the isometric camera, i made a new game typed called MMGame.uc

code

class MMGame extends UTGame;

DefaultProperties

{

DefaultPawnClass=class'Prototyping1Mod.MMPawn'

PlayerControllerClass=class'Prototyping1Mod.MMPlayerController'

MapPrefixes[0]="MM"

}

This basically extends UTGame so we still have the gun, announcements, HUD, etc, but is made to point at a new PawnClass and PlayerControllerClass that must also be defined. Here is the PawnClass MMPawn.uc

code

class MMPawn extends UTPawn;

var float CamOffsetDistance; //distance to offset the camera from the player
var float CamHorizOffSetDistance;
var int IsoCamAngle; //pitch angle of the camera

//override to make player mesh visible by default
simulated event BecomeViewTarget( PlayerController PC )
{
local UTPlayerController UTPC;

Super.BecomeViewTarget(PC);

if (LocalPlayer(PC.Player) != None)
{
UTPC = UTPlayerController(PC);
if (UTPC != None)
{
//set player controller to behind view and make mesh visible
UTPC.SetBehindView(true);
SetMeshVisibility(UTPC.bBehindView);
UTPC.bNoCrosshair = true;
}
}
}

simulated function bool CalcCamera( float fDeltaTime, out vector out_CamLoc, out rotator out_CamRot, out float out_FOV )
{
out_CamLoc = Location;
out_CamLoc.Y -= Cos(IsoCamAngle * UnrRotToRad) * CamHorizOffSetDistance;
out_CamLoc.X -= Cos(IsoCamAngle * UnrRotToRad) * CamOffsetDistance;
out_CamLoc.Z += Sin(IsoCamAngle * UnrRotToRad) * CamOffsetDistance;

out_CamRot.Pitch = -1 * IsoCamAngle;
out_CamRot.Yaw = 0;
out_CamRot.Roll = 0;

return true;
}

simulated singular event Rotator GetBaseAimRotation()
{
local rotator POVRot, tempRot;

tempRot = Rotation;
tempRot.Pitch = 0;
SetRotation(tempRot);
POVRot = Rotation;
POVRot.Pitch = 0;

return POVRot;
}

defaultproperties
{
IsoCamAngle=-7420 //35.264 degrees
CamOffsetDistance=64.0
CamHorizOffSetDistance=-64.0

}

A good bit of this code is taken from the UDN example, however, i wanted to change the offset distance and angle, so i adjusted those to be closer to the player and look "upwards" instead. Then, i added a variable CamHorizOffSetDistance to move the camera off of the player a little bit so he wouldn't be directly in front of the camera, blocking the player's view. I assigned its value to CamLoc.Y to make this happen. Next was the PlayerController, MMPlayerController.uc

code

class MMPlayerController extends UTPlayerController;

state PlayerWalking

{

ignores SeePlayer, HearNoise, Bump;

function ProcessMove(float DeltaTime, vector NewAccel, eDoubleClickDir DoubleClickMove, rotator DeltaRot)

{

if( Pawn == None )

{

return;

}

if (Role == ROLE_Authority)

{

// Update ViewPitch for remote clients

Pawn.SetRemoteViewPitch( Rotation.Pitch );

}

Pawn.Acceleration = NewAccel;

CheckJumpOrDuck();

}

function UpdateRotation( float DeltaTime )

{

local Rotator DeltaRot, newRotation, ViewRotation;

ViewRotation = Rotation;

if (Pawn!=none)

{

Pawn.SetDesiredRotation(ViewRotation);

}

// Calculate Delta to be applied on ViewRotation

DeltaRot.Yaw = 0;

DeltaRot.Pitch = 0;

ProcessViewRotation( DeltaTime, ViewRotation, DeltaRot );

SetRotation(ViewRotation);

NewRotation = ViewRotation;

NewRotation.Roll = Rotation.Roll;

if ( Pawn != None )

Pawn.FaceRotation(NewRotation, deltatime);

}

defaultproperties

{

}

This one used almost exactly the UDN example, as it is very well put together. The only thing i changed was the DeltaRot values so the player was fixed to look at the wall. Since the player needs to always be looking at a specific wall, i limited their control so that it responds directly with the pawn on the screen. With this, 'W' always made him move close to the wall, 'A' always to the left, 'D' to the right, and 'S' backwards. This representation, i felt, was much more natural for the game.

Here's a short video of the results.

Prototyping 1 Designer Diary - Week 3

2011-11-13T11:09:00.001-08:00

This post is taken directly from my Week 3 Assignment for Prototyping 1 at Full Sail.

"This week, we were taksed to make something that could be played with inside UDK using the knowledge gathered during the month. Our "toy" should reflect the concepts taught in previous assignments, yet be usable and represent some sort of game mechanics.

I chose to recreate a popular mini-board game called Mastermind. The concept behind mastermind is that one player picks a combination of 4 different colored pegs. The other player guesses a combination of colors, but their only feedback is how many are correct, and not which ones. The guessing player has 10 tries to get it correct, or they lose the game.

I started off on Monday by building the structure of the game mechanics in kismet, and representing the colored pegs as lights inside UDK. I also made a "guess grid" out of lights on the wall that would show the player's previous guesses. The player was to walk up to the light, and "use" the trigger placed upon them to cycle through 4 colors of light. I created a kismet sequence that would assign each of the 4 lights an "index" number that associated with a specific light color, and had kismet turn on the corresponding light per index. Once the player was satisfied with their sequence, they could submit their guess by shooting a mesh nex to their light selections.

On Tuesday, I had to figure out a way to get the guess to lock into the grid on the wall. I created a kismet object that looked at an int variable that was incrimented with each submission to assign the currently selected lights to a the corresponding guess row. This feature was complete and i was pleased with the results.

On wednesday, I added the win/lose conditions and a flythrough sequence that explains to the player what to do prior to the game starting. After this was complete, it was test, test, test. I changed the game to always randomize the winning light combination, that way each game is new.

All in all, around 1100 kismet objects is all it took to do the game logic and manipulate over 200 lights. In retrospect to building the game, i should have worked first on getting the core rules coded first, as i had to do some backtracking on other features like the previous guess grid and re-do some work. After this assignment, I feel even more confident in working in kismet, as I now have the power to create the blocks that dont exist, or create a single block that would replace a number of others in a specific sequence if necessary. "

Here are some screenshots, as well as a video showing some of the work.

Guess Grid and Selection Row

Overview in Kismet, Named Variables, etc.

Controller for Guess Grid.

Player Selection Row Controller for One Light (there are 4 of these)

Video

Prototyping 1 Designer Diary - Week 2

2011-11-07T06:12:00.000-08:00

This post is taken directly from my Week 1 Assignment for Prototyping 1 at Full Sail.

"This week, we were tasked to create a Kismet object in UnrealScript, as well as extend from an existing actor and override functions to make it "our own". After viewing the tutorial videos given by Rusty, a Full Sail Game Development alum, I felt comfortable in my new knowledge to crete the two objects i wished to make.

What I figured would be a stroll in the park was more like falling up stairs. See, falling down stairs is quite simple, as you just let gravity do the work. Falling up requires much effort, but hurts about the same. I found myself chasing class inheritance for hours only to find that the functions that i wished to override were buried in C++ instead of scripted for me to view. This limited my 5 or 6 ideas for my extended Actor down to only 1. This was only made clear to me, however, after i had searched out the way to do each of the abandoned ideas for hours, only to move on due to lack of time. In the end, i learned quite a bit of the structure of how UDK uses UnrealScript and how heavily it relies on it. This makes it useful for developers, as a good bit of the things they are doing with the default setting are transparent and readable in code.

For the Kismet object, I felt a little more comfortable. I currently work a job that has me doing similar things with Java and off-shoot programming languages similar to java by writing small scripts and compiling them into engineering blocks for use on a visual editor. My sequence block came out great and took hardly any time in comparison to the other half of the assignment. Once I had figured out that all of the objects act upon an impulse on the inputs, i felt i knew precisely what i was doing. I was about half-right, but some testing set me straight, and I loved the process.

Working in Visual Studio is nice, however, it becomes cumbersome to test your code in UDK when both cannot be built simultaneously, and often times i found myself shutting both IDEs down in order to get scripts to save/build/load/etc. I wouldnt think it would be too hard for Epic to include an UnrealScript editor inside UDK instead of having to swap programs so often.

Overall, I gained a good bit of knowledge this week working in UnrealScript, and I already have some more ideas of Kismet object that i want for my personal projects, as well as things i know will come in handy in future assignments."

Here is a script i wrote that made a sequence checking block. Essentially, it has 4 input impulse links, that have to be activated in sequence in order for the "Correct"
output link to fire.

class SeqCond_FourSeq extends SequenceCondition;

var int getVal;

var int setVal;

function fireOutput()

{

OutputLinks[getVal].bHasImpulse = true;

}

function setFourToZero()

{

if(getVal >= 4)

{

getVal = 0;

}

event Activated()

{

setFourToZero();

fireOutput();

getVal++;

setVal = getVal;

}

DefaultProperties

{

ObjName="Four Sequencer"

ObjCategory="Stager"

InputLinks(0)=(LinkDesc="Next")

OutputLinks(0)=(LinkDesc="First Out")

OutputLinks(1)=(LinkDesc="Second Out")

OutputLinks(2)=(LinkDesc="Third Out")

OutputLinks(3)=(LinkDesc="Fourth Out")

VariableLinks(0)=(ExpectedType=class'SeqVar_Int',LinkDesc="GetVal",PropertyName=getVal)

VariableLinks(1)=(ExpectedType=class'SeqVar_Int',LinkDesc="SetVal",bWriteable=true,PropertyName=setVal)

}

And here is a custom gun and projectile that i created by extending a couple of existing weapon and projectile classes. Pretty simple stuff, really.

Weapon

class UTWeap_LightBallGun extends UTWeap_LinkGun;

DefaultProperties

{

WeaponProjectiles(0)=class 'UTProj_LightBall'

WeaponFireSnd[0]=SoundCue'A_Pickups.Ammo.Cue.A_Pickup_Ammo_Respawn_Cue'

MaxAmmoCount=500

AmmoCount = 500

}

Projectile

class UTProj_LightBall extends UTProj_Rocket;

DefaultProperties

{

ProjFlightTemplate=ParticleSystem'VH_Scorpion.Effects.P_Scorpion_Bounce_Projectile_Red'

ProjectileLightClass=class'UTGame.UTRocketLight'

ProjExplosionTemplate=ParticleSystem'CTF_Flag_IronGuard.Effects.P_CTF_Flag_IronGuard_Spawn_Blue'

ExplosionSound=SoundCue'A_Gameplay.A_Gameplay_PlayerSpawn01Cue'

AmbientSound=SoundCue'A_Gameplay.JumpPad.JumpPad_Ambient01Cue'

Speed=0

ExplosionDecal=MaterialInstanceTimeVarying'WP_RocketLauncher.Decals.MITV_WP_RocketLauncher_Impact_Decal01'

DecalWidth=128.0

DecalHeight=128.0

LifeSpan = 4.0

}

Prototyping 1 Designer Diary - Week 1

2011-11-07T06:05:00.001-08:00

Note: This should've gone up last week, but better late than never, i suppose!

This post is taken directly from my Week 1 Assignment for Prototyping 1 at Full Sail.

This week’s assignment was a nice change of pace from building actual products to making a sort of “demo box” level in UDK. When reading the overview of the assignment, I had knew I had a decent grasp on things that were necessary in order to complete the assignment, however, the things that I didn’t understand or had not done were not just unfamiliar to me: they were completely new tasks.

The largest learning was taken from the changing of physics and setting object locations inside kismet. The idea of resetting something’s location was something I had never thought of doing before, and is a task that I feel I will use heavily in non-fps type games in the future. For instance, in board games like chess or checkers, the game reset could be done this way, allowing me to make 3d board games inside unreal.

One thing else that I learned was how to work with skeletal meshes. This, too, I had never even taken the time to consider. Since I typically find myself lost in creating “places” or “worlds” in unreal, making things come to life has never been on my to-do list until this assignment, and I have grown because of it.

Doing this assignment gave me some extra tools when considering prototyping. Before, I felt that Unity was the easiest way to get a concept running and proven before hitting a hard development schedule, but now I can see ways that we can do a lot of the same things in UDK. A question that I feel can be answered from this is “Can I make an instance of gameplay that is easily resettable in order to test repeatedly in order to get good statistics for play balancing?” The answer is yes. I look forward to getting more involved in UnrealScript next week so I can have a little bit more power in making the things I want to happen a reality in order to test mechanics.

Here is a fly-through video. Disregard the visual ugliness, this is only made to represent use of interactions, like Take Damage, Triggers, Assigning Physics, Animations, all through Kismet. Also, some screens!

Top Level Sequence

Room 1

Room 2

Room 3

Room 4

Room 5

Level Design 2 - Postmortem Assignment

2011-10-24T09:25:00.000-07:00

In Level Design 2, all of the students were placed into a random group and given the task to create a fully functional UDK level as a team. Team Ice decided that we would create an Alaskan themed single player level with combat encounters as well as an escape sequence that, if failed, ended in the player’s death. We decided to split the map up into 4 sections and each work our own room with the end goal to make one large level. These were then streamed into a single persistent level, and the kismet was stitched together between them using remote events and named variables. We wanted to give the player a feeling of struggle on the way in, and danger and haste on the way out.

What Went Right

1. Kismet Level Streaming – Getting the levels put all under one roof was a bit of a daunting task for someone that had never done it, but I was most worried about how we would get our kismet working. At first I was unsure where our named variables had to be, but once we moved them into the persistent level, we could use them in any of the subsequences below. This allowed each of us to work on our own interactions per room, and then when alpha was due, I stuck them all together in about an hr. After the groundwork was done for the kismet integration, the rest of the interactions and tweaking them were very easy.

2. Scaling Rooms Prior To Building Geometry – Luckily, Wayne thought ahead when putting together the mock and placed it on a grid that we could build on. It took very little time to get the geometry looking as it should look the first time around. Very few changes occurred to the BSP positioning after the fact. We could have ended up wasting many hours getting these things straight, but having the interactions paced well on the mock and the mock having measurements placed on it facilitated the process and made it possible to slap down within an hr or so.

3. Scoping the Project Early – Like many creative ideas, it’s easy to get out of hand with everything that you want to have accomplished. Knowing what we had to accomplish in such a short amount of time, we spoke early of what the level absolutely needed, and prioritized on which interactions would make the product better. This let us meet our goals (for the most part) as well as polish the environment a bit and balance the interactions as best as we could. I feel good about the decision to let things hit the cutting room floor instead of sacrificing the entire product just to have “more” in the level

4. Using DropBox and a Windows Junction – We ran into an obstacle early in week two with understanding how level streaming in Unreal is handled by confirming that streamed maps must be under the UDKGame\Content\Maps folder of the build of UDK. We recognized how using DropBox would help us all have the latest versions of each other’s maps, but we would have to manually move them all to the correct folder, which would kill us for version control and time. I believe it was Kris that mentioned a method that we could use that would solve this problem. In the command line, there’s a way to make a junction between two folders that forces them to mirror each other on a save. We pointed the junction to a folder under maps, as well as our shared DropBox folder so each time someone changed their level, everyone would automatically have the updated one pushed to their Maps folder. This eliminated just about any file sending throughout the month.

5. Getting Out of Our Comfort Zone – Some of our goals in this project were outside of our existing understanding. We went into it knowing absolutely nothing about level streaming, nothing about path nodes, nothing about bots, and nothing about little about how to handle a checkpoint. Though we didn’t learn everything about everything, we have huge take-aways from this project because of the learning we were forced into, as well as something to refer back to on how we accomplished a task.

What Went Wrong

1. Level Overwrites – It didn’t happen much, however, on occasion, someone would overwrite someone else’s work due to us all working “live” on the levels. The auto-replication of the junction and DropBox forced all changes down to anyone else that was connected to the internet, and sometimes working in the persistent level meant that the sublevels would have to be saved. Some work was lost on two separate occasions, setting us back in progress. This made some of us a little gun-shy to work on things outside of our own level, such as global interactions or kismet in another persons level, and forced us to guess when others may have their map open. Communication could have helped us avoid this, and we could have scheduled our work times to let everyone know when who would be in which level for how long.

2. Working With the Latest UDK Beta – We decided to get into the September build of UDK and make that our standard for working this month. Things changed dramatically from the builds that most of us were used to, such as default Play In Editor game mode, location/availability of some meshes and materials, and viewport camera controls. I had a few issues with the stability of the build as well, and I know that it set Kris back some too with crashes and errors. I feel that if we would have decided to work in a build that we were familiar with and knew worked with our machines we would have been better off for productivity.

3. Responsibilities to Sections of Map Instead of Design Aspects – We were all responsible for a specific room of our UDK map, and some of us were responsible for other things that related to the map as a whole. I feel that because of this, we had a representation of 4 individual maps stuck together like different colored legos instead of one overall visual aesthetic. Each room showcases the maker’s talent, skill, and design theories, however, the map as a whole felt as if it was missing an important vein of familiarity. If we would have given someone the responsibility to handle all materials and mesh placements, another to design the lighting and lighting interactions, another to worry about particles and effects, and another the kismet interactions, I feel that the level would feel more seamless when looking at the integration, and make the product seem more of a single idea.

4. Not Enough Research on Bots - The combat encounters are the driving force of our map. They are what keep the player occupied on their way to their end goal. We didn’t know anything about them when we went about placing them in the level, so we had to do our research. Once we got enough knowledge of them down to be dangerous, we placed them all in the map where we wanted them to spawn, and all seemed well. It was not well. At first, the bots were killing each other, so we figured out how to team them up on the player, but that meant that the game type had to become a UTTeamDeathmatch in order for it to all work. Knowing little about how to make our own game type, we decided that this was an OK solution for this project. When it came to playtesting and trying to balance the interactions with the enemies, they acted so spontaneous that it was very difficult to pace out parts of the level and provide the player with more than one path to get to their goal. Often they would even just commit suicide, leaving us with no interaction at all. We should have focused on fixing these issues so the level would be more enjoyable to play instead of feeling meaningless in some areas.

5. Areas of the Map Didn’t Get the Attention They Deserved – The gold turn in of the map, I feel could still use some work with lighting and meshes. Areas seem a bit scarce still, and don’t seem to serve any purpose whatsoever. I think we could have focused on finding these dead zones and made them more interesting, as well as possible including meaningful interactions inside of them. If they serve no purpose whatsoever, they should not even be in the map at all. I’m not necessarily talking about the areas that the player cannot access, as those fit the level and give a nod to the believability of the game world, but we had areas the player could access that felt a little incomplete or could have been removed from the map altogether.

Overall, I feel that the product came out well. Given the time and tools we had to work on it, Team Ice delivered the complete idea in a useable form. We felt that we had met our goal of directing the player’s thoughts at the times we wanted to and that we got all of our designed interactions into the map by the deadline.

Short Update - Level Design 2

2011-10-13T06:50:00.000-07:00

Hey all, Its been a couple weeks since I have posted, so I figured I'd drop quick update.

Currently, I'm working through Level Design 2 at Full Sail with a group of great designers and hard workers. This month, we are collaborating on a big level, and trying to get to a beta phase of the project by Sunday. We were encouraged to use level streaming, and stream levels we did! I picked up a good bit of info on how kismet sequences work across streamed levels as well, and our project is shaping up. I will have some pics of it up sometime after it is completed, with some explanations of how we had to accomplish some things working as a group. Kris Kirchman, one of our members, suggested that we use junctions in Windows to leverage our dropbox shared folder as a means of collaboration. In short, streamed maps need to be under the UDK/Content/Maps folder of the UDK build, so the junction replicated a folder there from our shared Dropbox, and all are mirrored across all 4 of our computers. Genius though, and more about how to do it on W ayne Denier's blog here.

We dissected the map into 4 sections, where each of us did the geometry, meshes, materials and lights for each, however, I am beginning to think that we should have streamed those things as individuals, and assigned one to each of us. For instance, One level should be geometry, one should be lighting, one should be meshes, etc. I see a difficulty in us working on the beta build when working on other peoples levels, because I fear many overwrites are going to occur, setting us back. This is going to require us to have better communication, and work more methodically instead of how we are used to as online student: when we can.

Hope all is well, everyone.

UDK Level Project for Last Level Design 1 Assignment

2011-09-24T14:12:00.000-07:00

Hey all, I just completed putting together the back room for my Level Design 1 project, and I wanted to share some screens of it. There's a bit of behind the scenes Kismet going on, but for now, here are just some visuals of what I had come up with. Click to enlarge, friends.

It could use some attention in a few areas, however, I am pleased with this as the turn-in.

Happy Fall, Y'all!

-ivey

Level Design Updates / School Project

2011-09-19T20:13:00.000-07:00

Hey all, just wanted to check in and give a little update as to whats been up. The past few weeks have been pretty busy with school, so I haven't done much with my personal work, unfortunately. Last week, however, we were to go through a tutorial and add some things to it, so i figured I'd post some pics of my turn in last week. This week, we will be further tweaking it and Ill drop that stuff here as it comes in. Normally I wouldn't post non original content, however, i got gained some knowledge from making this that I'd like to share

So here's the scene

Basically, its these 3 towers set in a cliff surrounded by a small outdoor scene. It has a few different kinds of lighting as well as water volumes, BSP brushes, and very many scaled meshes.

Going into the project, I was a little discouraged by the assignment being just a tutorial. However, I learned some things along the way with this one.

Lens Flares: They do exist! and they aren't difficult to make.
Ambient Lighting: D'oh... I had literally been making Big-Ol' Lights.
Dominant SpotLight: I understand how you work now and that your placement does not matter.
Post Processing: Such a powerful part of the toolkit. So many tweaks to make levels look way, way better than before
Scaling In Compatible Numbers: Without this, your meshes will overlap and not fit right. And you will be sad. And frustrated. And sad.
A Useful Way To Use Brushes: After I had spent a good few hours in UE3 and UDK, I decided that BSP brushes were pretty useless when compared to a mesh. This still is the case, however, I picked up on ways i can use BSP to enhance a level and fill gaps that i desperately need to fill.
Water Volumes: Yay swimming.

Here's a short vid of a simple sequence i added for my "flair" part of the assignment. It's not much, but it was entertaining.

Gears of War Editor Vs. UDK

2011-09-16T13:25:00.000-07:00

So i really enjoy working in UDK. its nice because te toolset allows you to accomplish things very quickly and iterate the design of levels. It does, however, have one huge void, and that is content. The toolset has a good bit of static meshes, materials, and all, however, they dont necessarily meet all the needs of the designer. I can still make some great things using them and thinking "outside of the box", however, i feel a bit limited and almost as if im fooling even myself by doing so. The toolset is mostly the same as before, with very many time cutting features like enhanced movement in the world viewport, detachable viewports, drag and drop-able assets, and others.

Gears of War Editor, however, has the exact opposite problem. I find the meshes and assets in it are plain awesome. I wish like hell i could export them all and use them in UDK, but the fact is that i cannot. The tool uses an older main buil of unreal engine 3 (i believe 490?), and I cant use the packages in UDK. Also, since its older, many of the great features such as drag and drop, WASD movement, and little widgets I've grown to lean on do not exist, making the process much more time consuming. The rotate widget really frustrates me too.

Enough bitching, though. Both are great tools for level design, and will both prove to be great places for me to feel out my designs. Being almost done with Level Design 1, i now have 2 new maps that i wish to create in one or the other tool. Seeing how quickly i can put things together in UDK, i will most likely take that route. I have found very little differences in them involving Kismet, so that makes no difference i dont believe. However, I really must make a city map in gears because the assets are just too good.

UDK Snow using ParticleSystem

2011-09-14T19:02:00.000-07:00

Hey all, just a quick little thingy i made today in UDK while goofing about. Its a small level Ihave put together because I wanted to test the ability of snow using a particle emitter. Though it is not likely that this word work well in larger areas, it is kind of cool to see it work. I had to use many of them in 512x512 boxes over the map in order to make it cover correctly and fall more realistically. Since a particle can only have 500 textures on the screen at a time, tuning that down with the velocity and lifetime took a few tries.

Check it out!

iPhone Development - My First Project Experience

2011-09-08T07:27:00.000-07:00

I think its the same with everything new in life that a person learns. No matter how prepared you are, you aren't going to have all the bases of knowledge covered for a project. Late last spring, I decided to take my short history in iOS development and take on a client. I sure have learned a ton over the past few months, and here's some things i feel about the iPhone, Xcode, Objective C, and mobile development altogether when retrospectively looking back.

The iPhone is a remarkably powerful device with a good bit of intelligence built right in. Some view it as the end-all pocket device and hold it rather high. As most of you probably know, I'm not necessarily an iPhone fan. You most likely wont hear that from a ton of other iOS developers, but for personal use, I prefer Android or WP7. After this project, however, i have grown to enjoy the device as a tool instead of a phone. I understand the need for a consolidated platform in the pocket, but i see it as a multitool for tons of other applications, and I plan on continuing my venture into creating for it.

The SDK for the iPhone comes packed with one mammoth of a knowledge base. If anyone has good documentation, its Apple. More often than not, if i found myself in a situation where I was using one of their widgets or functions and needed assistance in finding out what the hell I'm missing or doing wrong, the documentation usually pointed me right where to go. The ONLY problem i found with the SDK is that it only runs on a Mac. My main development computer is a smoking PC that is comfortable to work behind, and this entire time i had to code at a laptop with a smaller screen. Not a big deal, but a little openness would be nice. Overall, i enjoy the IDE. everything is where it needs to be, and works together quite well.

I could say a lot about Objective C, but I'll keep this short. It's a frustratingly cumbersome, patchwork-ed together language that has a feel more abrasive than C++. In a world with so many proficient high-level languages, this shouldn't be a standard or something that we are forced to work in. That is all.

As far as mobile development goes, it is gaining a ton of attention from a ton of industries, as the user-base is growing so vastly. stackoverflow.com really saved my ass many times during the cycle of this app, and I am thankful that so many developers are working in iOS, as most of them are willing to share horror stories and help with questions about how to accomplish something. The internet is an invaluable source of info, and i feel that I have learned more from other developers and myself asking questions than I ever have from a book or tutorial videos.

On the waning side of the app development life-cycle now, I am more proficient in how the iPhone manages memory, im a master of the UITableView and its friends, I can handle storing, writing, displaying, sorting and all sorts of other SQLite commands, and have a firm understanding on how the UIViewController works. I'm rather thankful for the experience.

I still have very much to learn, but having this project has put me worlds beyond where i could have been without it.

-ivey

Video Game Industry Vs. Music Industry

2011-09-07T15:51:00.000-07:00

Its not uncommon to hear people compare one sort of entertainment media to another, and professionals from different industries often swap roles to take on business positions at others. Unfortunately, most of the American entertainment industry is, as are most industries, solely driven by the mighty dollar, putting the power in the hands of those that have it. In music, this would be the record labels. In film or television, this would be production companies or networks. In videogames, this is the publisher.

In the music business, its not uncommon for a band or artist to sign on with a major label, have their music bastardized, and be dropped after one or two records, leaving the label infinitely richer and the musician screwed. When i say it is not uncommon, it is practically the norm. This is really discouraging for a hopeful hometown hero or weekend warrior, and causes the life of a musician to be one of the following:

- That of extreme poverty while doing an art you love. This accounts for the vast majority of anyone who gives music as a career choice a shot. They usually end up in cover bands for a few years (sometimes decades).

- Having medium success while having someone else direct your art. Any band that stays in this stage has the best scenario, as they are getting paid (typically not much) to do what they love, yet they have a small bit of compromise to someone else's agenda. This typically does not last long, as the record companies will make their money on the band and directly or indirectly move them into one of the other two categories listed.

- In the smallest percentage cases, musicians become a sort of puppet for some men in suits that use them to get richer. Most bands when they get here have lost the hunger to create like they did, so being a puppet is OK, as they dont have to try as hard to "Make It" anymore. These cases are why we have such terrible popular radio, and why so many great bands grow worse with each record.

In any of these situations, what a musician would call "success" is limited and wanes fairly quickly. Isolated cases exist outside of this model, but this really accounts for almost all of the record industry. The only ones that win in these cases are the record companies. The artist gets screwed, and the fans get screwed out of receiving a better product, which is why piracy is so rampant.

Going independent as a band typically means a good bit of do-it-yourself type work. You never know when you'll have successes or failures, and you often times have more obstacles in getting exposure to markets than the bands that have funding. It's a risky thing only for the truly committed. Sometimes it pays off, sometimes it does not. Just know that the amount of work hours is uncountable. For few, this is the best life they could ask for.

I like to hope that the video game industry is not destined to follow this same path. We are seeing it now with these larger, bullish publishers run by non-gamers, and it makes me weary to get into the big business of games. Indie games are becoming easier to get out to people, but what about that hunger to create a vast masterpiece such as Gears of War? That is an example of a game that could not be possible without a large budget and would be much less of a great game without it.

While games budgets are growing and publishers are gaining more and more leverage over the developer, the games being put out are often times top-notch productions with the highest value. Nothing against indie games, but a certain experience exists in playing a game who's production was an undertaking as daunting as World of Warcraft, Bioshock, Dead Space, or Red Dead Redemption. At the same time, many of these high dollar productions end up being complete trash, causing the success/fail rate to be about even. I have played a ton of indie games that i would rank higher in player experience than games such as Duke Nukem Forever, Lost Planet 2, or State of Emergency.

The growing Indie scene is a great thing for games, because i think it is forcing big publishers to take note that they aren't the only outlet to procure great games from. They are gaining enough attention that they are even getting purchased by publishers for tens of millions of dollars in order to gain their piece of the market as well. But how long will it last? Will there be a time where there is a good balance of funds into independent development that can afford the developers the opportunities to make their games to the highest quality? Or will the Indie developer be just like the Indie musician that works twice as much, has a feast or famine life for the rest of his or her career, and ultimately gets very little for their efforts?

As a game designer and developer, I hope to not grow jaded of the industry. I want to be a part of something huge, however, I fear that the way things are going could lead to a world where developers are just "employees" instead of artist, taking orders from the big boss man because it is the only option. Here's to optimism! and continuing to press on for the sake of the passion of the creative art of games.

-ivey

UDK Level Tweaks - Adding Environment Effects

2011-09-05T19:43:00.000-07:00

Hey all. I wanted to show some of the things i did to my level in UDK this weekend. Ive been working more with materials and their properties, so the level now has rain and some cliff fog.

Here's the cliff fog video

http://www.youtube.com/watch?v=dR3eeDM99ls

It was made by using a simple foggy texture with some material manipulation and applied to a particle emitter. I made it small enough that i could place them only on the cliff edge and not in the level itself.

And here's the Rain.

http://www.youtube.com/watch?v=SLt2dcnk1BM

The rain is made by using a scrolling material with an alpha channel, tossed on plane materials. tweaking the settings in the material, you can fool the effect that its not just on a bunch of flat surfaces.

Also, im toggling these in Kismet. The sequence page is getting larger by the minute!

More to come later!

-ivey

Encounter-Based Level Design

2011-09-01T08:10:00.000-07:00

I had a reading assignment in Level Design 1 about encounter-based level design that brought up some important questions and concepts to me. If you are unfamiliar with the method, it essentially means to create a level around the things you want your player to encounter or experience at that point in your game.

I find that declaring what is going to happen in a level will immensely help the pacing and unpacking of specific experiences and allow the world to have "purpose" other than a "just because" world that a player can move through. Having an importance of the surroundings in specific situations makes a huge difference and promotes immersion even further. I like the idea of creating a timeline of encounters, describing the encounters, then laying them down on a map. Once they are there, you know where to lead your player, and you can provide visual clues and other environmental assets to drive the game.

If the encounters you want your player to have in a level pertain to them learning a new ability, It is important to make sure the level has plenty of places that they are required to use it, or can use in previous areas where they recognized a reward that they know is possible to get to, but they know they don't have the ability to do so yet. Many times in games i find myself learning or acquiring new abilities that I'm not forced to practice immediately, and i quickly forget about them or never develop them in the ways that i need to because the level is not designed around that encounter. A recent game that does this well is InFAMOUS on PS3. Each time you get a new core ability, the sewer level you get it in is designed to where you HAVE to use it to get back out. This keeps the new idea fresh on the players mind, and they can grok the controls and practical use of it in a quicker manner.

A question that encounter-based level design brings up to me, however, is how is this implemented in multiplayer situations? When you have human vs entity interactions, the spectrum of possibility is so much larger that level scope becomes very important, as you want to hone in on what you feel are the important encounters or experiences and not overwhelm the player(s) with too much possibility. How do you find out where those lines are, and how do you tune the experiences in to where they are going to be the best for the level? Im sure that experience comes in handy here, as I have none with MP maps, but the idea of a second "thinking" entity on your map really makes things interesting.

-ivey

Level Design 1

2011-08-30T16:14:00.000-07:00

Started Level Design 1 this week at Full Sail University. Currently, I am sitting in an empty Wimba Virtual Classroom awaiting the professor and a possible other student or two. Its crazy how in the beginning these kinds of chats were imperative, but now have become a thing of leisure instead of necessity. Fewer and fewer student show, but that's OK.

Assignments this week have to do with blocking out (on paper) a level for Left 4 Dead. I, for one, have never played the game, though i believe that it's about damn time i forced myself to do such. When this meeting is over, I will be heading to the closest GameStop.

Pertaining to level design in general: Isn't it important to understand the mechanics and overall "idea" of a game before even getting involved in creating the world around it? Some may agree, and some disagree, but I find it quite frustrating when a world and the way a game works dont mesh very well. Many levels seem created in the grand scheme of things from an artistic standpoint of and simply make an area that a game will someday take place. Very few games, however, make use of the maps in a way that nods to the mechanics and how they all work together. It almost seems as if an entire area is made, and then specific little spaces inside are tuned to how the game plays. If not that, the world is made so fundamentally linear that the player has no choice but to follow a path that turns and is hidden by static meshes and textures around a lifeless tunnel.

I hope to work against that thought and make what i create add to what the game is, and not what the scenery is. A level should provide affordances to and lead the player, while still working heavily with the core mechanics of the game to create a dynamic experience with each playthrough.

cheers.

-ivey

Design Tools 2 Final Vids

2011-08-30T05:32:00.000-07:00

A couple of vids from the UDK project.

This video has a short cinematic focusing on an obstacle that the player has to overcome. The player uses the rocket launcher to blast the stones away to make a path

This video is just a simple cinematic sequence.

-ivey

Design Tools 2 Final Screenshots

2011-08-29T07:41:00.000-07:00

Here are a few screens from my Design Tools 2 UDK level. The images are a little rough, and ill have some better ones up later, but this somewhat shows it off.

-ivey

After the Short Break...

2011-08-29T06:23:00.000-07:00

I have returned, and it is a good thing.

Over the past eighteen months, i have been enrolled full-time at Full Sail University. During my time there, i have gotten married, been to E3 twice, met some of the most influential game developers of our time and times past, worked with some of the most amazing other students in classes, developed an iPhone application for a client, and soaked up a good bit of knowledge and wisdom from all of the above. I just finished Design Tools 2, and Level Design 1 begins today, starting the one year countdown until my graduation. I look forward to my departure from school and my continuing journey into game development, and here is a small list of the largest concepts that i have gathered in my time.

In no particular order...

You Will Never Know It All - The humble developer is the growing developer, and understanding that there is always room to grow is an incredibly important part of development. The press to out-do and out-design will push the industry into something greater every time, and history has proven this. Not to mention changing technologies and new possibilities, it is important to continue to learn until the day you die. Like the musicians that got stuck in the eighties, designers and developers can be left behind.

Don't Be Afraid To Speak, and NEVER Fail To Listen - As a designer, especially, feedback is the most important thing when presenting an idea. It is, however, important to be able to clearly portray your ideas to others and develop a constant connection of communication. A misunderstanding in speaking or failing to properly listen can be detrimental to your design or a project.

Let Go - Owning an idea and wanted to protect it is a good thing in any creative art. When working with a group, however, it is important to let the group work as that: a group. This often means compromise, and though it should be questioned and fully discussed, new ideas to your idea or changes made by others should be embraced, as the goal is still common: a good game.

Experiences Make Games - As a child, we are by nature game designers. Mostly because we want to have fun, and we make it from our situations. Jesse Schell has a good bit of writing in his book about this, but always remember: In everything you do, there is a game. Find it.

Networking is Imperative - They say its not always what you know, but who you know. Well in the games biz, I am finding this to me more and more true. It isn't everything, but it may be enough to help take your skills and talent somewhere that they couldn't get you on their own.

Leverage Social Networks - With Networking comes networks, and there are few better ways to meet or keep in touch with other developers/designers than social networks such as twitter, Facebook, and LinkedIn.

Finish Ideas - A difficult thing to follow through with, a polished product, will always look better than an incomplete idea. This ADD world of ours (especially for gamers) lets us jump from one thing to the next so easily. Don't get trapped. Completion Completion Completion.

Learn To Code - As a designer, understanding a programming language can really help you understand the capabilities of a game. It also puts you closer to the interactions of your PC and the game world, and can open up new ideas for you to work with. Thinking as a coder helps compartmentalize different aspects of objects, and can help you refine independent game mechanics as well. Scripting definitely is a must here at some degree.

I am sure there is a ton more, but that's all that comes to mind as of right now. I will have some screens and maybe a video from my final in Design Tools 2 later this week, and some other retroactive posts about things i have created in the past few months.

Sorry for the absence, Its been a busy life.

-ivey