|
Between June and
September of 2006, I interned at Gearbox
Software, working on an unannounced
next-generation title built on Unreal
Engine 3 technology.
My daily work
consisted of general gameplay programming tasks,
ranging from minor bug fixes to implementing new
systems. The programming aspects of this
title revolved largely around the concept of
data-driven systems, and as such, my code was
designed to expose all relevant parameters to
the editor. A simple example of this was one
of my first tasks, which was to provide a method
for specifying weapon impact and footstep
effects. These needed to be capable of
playing a sound effect and spawning particles,
but the specific sounds and particles were to be
specified by a designer within the realm of the editor.
Much of my work
on this title was related to the HUD. One of the largest of
these tasks was to implement a guidance system
consisting of dynamic waypoints for quests,
fixed markers, and a compass. These all
needed to be completely controllable by
designers within UnrealEd and Kismet. I
also implemented and refactored the HUD's
directional damage indicators as they went
through a number of design changes. The
final HUD task I worked on was an item feedback
feature which would display markers around items
in the world and provide textual information
about the item when the player approached it.
The textual portion of this feedback required
implementing a way to display images inlined
with text, while ensuring that the output could
still scale and wrap properly, as text
ordinarily would.
One task in
which I was given a considerable amount of free
rein was a homing projectile system. I was
given a set of requirements regarding how these
would behave and how they would tie into other
elements within the code and within the editor,
but the specifics of the homing motion were left
up to me. My initial approach was to only
adjust the acceleration of the projectile (as
opposed to also adjusting its velocity) so as to ensure smooth
movement. This introduced some interesting
problems within the bounds of the Unreal engine,
as projectiles are typically expected to travel
in a straight line, so they use tear-off
simulation; that is, the initial conditions are
replicated, and each machine then simulates the
projectile on its own. Because even slight
differences in the game's state between machines
would cause the homing projectiles to behave
differently on each player's screen, I had to
create a new projectile class which would
replicate its physical state each frame. I
also encountered another interesting issue in
which Unreal would automatically zero out a
projectile's acceleration once it had attained a
maximum speed. Because I was updating the
projectile's acceleration on a timer event
rather than every frame, there would
occasionally be periods in which its
acceleration would get nullified until the next
timer call, so I had to add a more frequent
check to make sure that this had not happened.
One of my final
tasks during this internship was to revise the
game's auto-aiming code based on designer input.
This was an interesting task in that it required
a fair amount of going back and forth between
world space and screen space, taking into
account the player's field-of-vision, the
position of targets, and other relevant
parameters. This experience turned out to
be invaluable, as I encountered some similar
problems when working on the camera system for
Toybox Heroes. |
