Embedded Files
First game I worked on as a professional, granted it was the first two weeks at Bioware and almost everyone was put on the credits. I spent those first weeks seeing if compression could be used to speed up the level load times, turned out it couldn't and the problem was solved another way.
Later I built a secret door addon for players to us in there own adventures, worked quite well and taught me never to give my work email to players!
KOTOR was my first game that I worked on that wasn't essentially done, also the first game I did for a console. Working on a console was an interesting learning experience. Who knew that data read and access speeds change with were an asset is placed on the CD.
For KOTOR I worked on the camera and control systems for the player and pathfinding for the NPC's. Additional work was done on the combat system with Aaryn Flynn.
The pathfinding system was based on a network of path points that were placed by level designers and provided a high level pathing information. For short range pathfinding a system of walking the navigation mesh of the level was used. This allowed for high precision navigation over short distances and around dynamic obstacles.
Mass Effect was my first exposure to the Unreal game engine, we spend many months adapting Bioware systems like Dialog and combat systems to the Unreal-3 engine. During this time I learned the pain of deep diving into another code base and being expected to adapt it on the fly while preserving the ability to merge updates from Unreal as needed.
I was responsible for a portion of the initial investigation into the Unreal engine. Additionally designed most of the game's AI interface for the design department to implement specific AI behaviors and scripted sequences. Part of this was to extend the pathfinding system to allow the Geth to jump between walls and ceilings. These pathfinding additions tied into Unreal's Kismet system.
Life took a turn for the new when I moved to Iceland to work for CCP on their flagship product Eve-Online.
This was the first time I had ever used Python in an embedded environment. I quickly became a fan of the model for fast, time sensitive code being implemented in C++ and the glue game design code implemented in Python or another dynamic language.
Due to my past experience with AI my first task was to design and implement a new AI for the Sleeper. The new AI was implemented as a stimulus-response AI. This allowed the AI for the first time to reevaluate its target and if it was not making any headway could switch to a new target. Additionally the AI now had the ability to target secondary effects on other targets, for example repair beams on allys and missiles on a secondary player target.
For Dominion I was part of the team that redeveloped the sovereignty system for players to capture and control 'null-sec' systems. These are solar systems where the NPC law and governments fear to tread.
The Sovereignty system had to account for many different game play styles, and account for time-zones. When you have a player base that plays 23 hours a day (one hour down time per day for server maint.). Player exploit the timezones to attack rivals when they are sleeping. As a result the design for the sovereignty mechanic underwent multiple complete revisions as the designers addressed issues.
In the end the sovereignty system was a success and player wars heated up with thousands of players fighting in single battles.
For Tyrannis the team I was part of designed and implemented a reengineering of the universe. Numerous inconsistency had been produced when the initial universe was generated from the random seed 42. For example there was a gas giant sized planet in the orbit of venus. An Earth like planet that was in the orbit of Pluto and twice the size of Saturn. Working with an astrophysicist a set of corrections were applied to make the universe make sense.
That was mostly an exercise of converting excel tables into SQl update statements.
The real feature of Tyrannis was the planetary interaction. Up until this expansion the planets had looked nice. Now a player could place a base on the planet and manage mining and resource processing. This was done by using a spherical harmonic color map to generate moving hot-spot resource maps. Game designers created the parameters that governed the availability of minerals based on planet types and location of the planets.
My direct responsibility was to design and build a system to generate the spherical harmonic maps for ~58,000 planets in eve. This was implemented as a distributed build system that drew on my experience doing a build system for GE. Multiple computers would connect into the Game Design server and request work, generate the Spherical harmonic map and upload the results to the SQL database. During the last run we had almost fifty PC working for several hours to generate the last data run before we launched the expansion.
For Incursion the team build a multi solar system event system called the Tale system. This allowed a player's action in one system to affect the state of another system. When an incursion started several solar systems were looped into a single event. These systems were then classified by the number of jumps from the HQ system. New encounters and NPCs were then created dynamically for those system. As the players defeated these encounters the combined progress caused successful waves of harder and harder encounters to spawn until the final HQ was revealed.
Part of the pre-launch set of an incursion required that the server cluster nodes be rebalanced to remove may unrelated services from those nodes. When an Incursion spawned the players would flock to the systems to be the first to gather the new loot. As a result the node balance which previously was distributed based on historical player usage for a given solar system had to be suspended. For the duration of the incursion the solar systems were remapped to a set of incursion nodes. These nodes had more memory, faster CPU's and less services running on them.
Page updated
Google Sites
Report abuse