Game Developer with 9+ Years of Professional Experience
https://www.linkedin.com/in/kristopher-horton-69a48513
Credits
| 2020 | The Ice Breathes (Interactive Fiction) | Writer/Narrative Designer |
| 2014 | vs Zombie (Mobile) | Game Developer (self-published) |
| 2013 | Hero Bash (Mobile) | Lead Designer |
| 2011 | Touch Pets Dogs 2 (Mobile) | Software Engineer |
| 2010 | Touch Pets Cats (Mobile) | Software Engineer |
| 2010 | Samurai vs Zombie (Xbox) | Game Developer (self-published) |
| 2009 | Guns Loaded (Xbox) | Game Developer (self-published) |
| 2009 | Sol Invasion (Xbox) | Game Developer (self-published) |
| 2004 | NBA Live 2005 (AAA Console) | AI/Gameplay Engineer |
| 2003 | NBA Live 2004 (AAA Console) | AI/Gameplay Engineer |
| 2003 | MVP Baseball 2003 (AAA Console) | Software Engineer |
| 2003 | NHL 2003 (AAA Console) | Software Engineer |
| 2001 | Ominous Horizons (PC) | Software Engineer |
| 2000 | Catechumen (PC) | Software Engineer |
Author of Interactive Fiction as K.R. Horton
This is a tale of a corporate attempt to harvest an ancient virus gone wrong, with you, the hero as the only hope to save humanity.
It features an ensemble cast of misfits struggling to tame a post climate-change Greenland.
It asks: What would the Oregon Trail have been like today?
The Ice Breathes isn’t your typical “Chose Your Own Adventure” but a heavily scripted light RPG.
Welcome to Greenland: Your best-friend died under suspicious circumstances… He left you his land… Inuit stories speak of an evil lurking under the ice… Can you survive? The Ice Breathes is an open-world narrative adventure.
https://talescreator.app.link/SLn56OtQ6sb?_height=900&_width=1440
While the story is epic in scope, the memorable cast of characters does the majority of the heavy lifting.
Some of the characters you’ll run into are lovable and charming…
…others are dark and sinister.
One of the challenges the player faces is navigating the social dynamics of this cast.
Each friendship comes with unique perks to aid in the player’s journey.
Siding with the Inuit allows cheap access to resources; siding with the corporations gives shortcuts to puzzles.
Beyond the story, several chapters of The Ice Breathes contain exploration mysteries that require clever problem solving.
Other chapters feature combat where both dice rolls and strategic decisions can turn the encounter to your favor.
There is a resource layer as well, as you can hunt and forage for goods and supplies.
These goods and supplies can be used to upgrade your gear for narrative and combat advantages.
You can also upgrade your vehicle, residence, gear and more!
The Ice Breathes has stayed in the top 25 for the Tales platform for over three years, even after the company’s pivot to focusing on interactive romance.
Many Tales writers have used The Ice Breathes as a style reference for both prose, use of audio cues, pacing, and mini-game design.
As a writer at Tales, I mentored junior writers in both game design and story craft, with a focus on building memorable characters, nailing cliffhangers, and developing re-usable and satisfying gameplay mechanics.
In addition to prose interactive fiction, I also created interactive graphic novels with Tales. The video below will give you a chance to see how the stories play on the tales platform without going through all the steps of downloading the app.
Mobile Game Designer
Release: May 2014
Platform: iOS
Genre: Casual MOBA
Development Team: 2
For Hero Bash, I was the lead designer responsible for systems, combat, characters, and narrative. Additionally I did all the art for the game and provided technical game design support.
In 2014, the MOBA genre was dominated by the Defense of the Ancients/League of Legends model: Attack down lanes, gain resources from takedowns, and upgrade your hero to become more OP than everyone else.
At EscBros, we wanted to make a casual, cooperative experience for mobile devices that would do for MOBAs what Smash Bros did for Fighting Games. That meant honoring the genre, while reimagining the elements.
One of the first decisions in this game design was based on the primary resource.
In MOBA games at the time, gold was a winner take all proposition. To make this more casual, the resource had to be non zero-sum. And to facilitate a low UI mobile experience, the gold needed to be physically present on the map.
Resource Requirements:
- Visible
- Non Zero-Sum
Scattering gold Diablo style for everyone to scramble to gather was one option…however that lacked visibility as to who held the most gold. It also only went halfway on the zero-sum approach to the resource. The solution? Fans. This made the primary resource both visible, and always up for competition.
To add an element of risk, the fans increased their value the more they watched heroes compete. The player could gather low level fans and turn them in for a quick score, or risk the fans’s loyalty in hopes of gaining much bigger payoffs.
This led to the first leg of the gameplay triangle: Collecting fans.
To collect a fan, the player needed to win in combat. Winning in combat depended on three factors: hard picks, soft picks, and skill.
The hard pick came from your hero choice. In MOBA tradition, once you picked your hero, you were stuck until the end (unlike games like Overwatch, where constant counter-picking was an option).
Soft picks, however, like items in DotA/LoL, are vital for keeping the individual gameplay session alive. For Hero Bash this seemed an excellent place to add a layer of cooperation. Items became team items, because they came from your team’s item spawners.
Those items came gift wrapped in a nod to Toe Jam & Earl.
Items were built on a counter-system.
Spending fans allowed the upgrade of item spawners from level 1 to level 4. This implemented the second leg of the gameplay triangle: Upgrades.
Each team had a base. That base had item spawners. Those spawners were either well protected or vulnerable. Upgrading the close spawners gave an assured advantage, and upgrading the distant spawners was a risky endeavor.
Stars indicate item spawn points. Green circles are the goals where fans can be returned. Red squares are impassible terrain, creating choke points.
The final leg of the gameplay triangle was to gather those items for use in combat. To add a layer of competition to the gathering, it was decided that enemy items could be stolen and used or merely thrown away!
With primary gameplay and soft picks established, focus shifted to building out a memorable cast of heroes.
Ultimately there were 12 heroes spread across 4 categories.
Hero Classes: Attack, Defense, Mobility, Special (Infiltration)
There ended up being a lot of data to manage. To keep code as simple as possible, abilities were designed to utilize a small set of styles, so that the designer could easily script any new abilities into the game without requiring engineering time.
Between each character’s intrinsic talents and all the available items, there ended up being over sixty abilities that could be cast in game. These shared a set of fifty elements, that allowed for very robust gameplay options.
Since the game was Free to Play, we needed an economy that players would be interested in paying into.
We choose a combination of currencies: hard (gems) and soft (gold).
Hard purchases focused on one-time purchases of cosmetic gear, and recurring purchases of XP boosts, more daily matches, and an in-game overtime boost to grant a very small overtime period in close matches.
Soft purchases were easier to unlock through gameplay, and were used for unlocking new heroes, weapons (which gave gameplay perks) and items that could be pre-loaded into inventory for the next match.
Unfortunately, we were out of our league when it came to marketing and user acquisition.
Modifications for the low player base were made to keep the game playable.
Ultimately, “If you build it, they will come,” never materialized for Hero Bash.
Our final takeaway: Find your audience before you make the game.
Software Engineer
- 6+ Years of Professional Software Engineering Experience.
To best describe my methodology and experience as a Software Engineer, I’ll present to you the story of NBA Live 2005’s AI rework.
At EA, I started in UI and quickly was promoted to strategic AI for NBA Live. There I created a data-driven zone defense system with an external visual editor that allowed game designers to tweak the defenses independent of engineer time.
After that, I was tasked with refactoring the legacy Ball Carrier AI.
The legacy Ball Carrier AI had been a direct port from the Sega Genesis era AI code. It was one giant function, that consisted of goto statements, a collection of unnamed variables (reg1, reg2, etc) and a complete lack of documentation. It was effectively a black box.
The legacy black box AI had several issues that needed to be resolved in refactoring the code. Primarily, the AI tended to dribble down the court, stop at the three point line, wait for five seconds, then make a random pass or shoot.
It never appeared smart.
Legacy AI Issues
- Predictable
- Cheated
- Unintelligent
- Difficult to Tune
To stay competitive, the AI cheated. Whenever it fell behind by ten points, it’s shooting percentage went to 100%.
A straightforward solution of refactoring the code into a well documented state machine could easily solve the black box issue, would improve the perceived intelligence, and could greatly reduce the cheating issue. However, static state machines still suffer from a degree of predictability. Tuning was also an issue, as it required significant engineer time to differentiate play-styles.
To solve both the issues with tuning and predictability, I decided to implement a dynamic state machine with data driven rulesets.
The system was divided into four sections. Player behaviors were generally shared for players on either the user or AI teams (shoot, pass to, dribble to, etc). There was some specific pathfinding for the AI to navigate when dribbling, but otherwise, this layer had a high degree of reusability and most of my work here was breaking large code chunks into manageable components.
Weighted logic consisted of a set of rules on why the AI ball carrier might make a decision. They included things like “If the player is open and within their effective shooting range, then use their shooting percentage as their weight.” Each potential decision also had a play-style weight associated with it. This way the AI could be customized to prefer to only shoot inside, or to pass more often, and on and on, so each team could play a different style of basketball.
The decision making was relatively straight forward at this point. The rules were sorted by weight, and depending on the AI’s difficulty, a decision was chosen. At higher difficulties, one of the top few rules would be chosen, while at the lowest difficulty levels, the AI would randomly choose from a much broader range, allowing easy AI to make poor decisions, like passing to a player who isn’t open. The lag between weighting the rules and making the decision could also be modified to give a sense of an AI that was just a little slow at reacting to the action.
Finally, because this was data driven, the AI could be tuned independent of engineer time. Also, because it was data driven, at the end of a play, the chain of decisions could be analyzed, allowing for metrics based tuning.
Several pros and cons became apparent as the system was implemented.
Pros
- Vastly More Competitive
- Emergent Behaviors
- Variable Play-styles
- Increased Efficiency
- Easy to Tune and Expand
- Looked Smart and Dynamic
- Tunable While Playing
Cons
- Edge Cases
The most important outcome of the AI refactoring, was when the new AI and the legacy AI played each other in head to head games, the new AI had a 100% win rate. It won every outing by ten points. The legacy AI had to rely on cheating to even appear competitive.
There is a wonderful joy in watching your AI demolish another AI.
While the original design had allowed for different tuning compositions for each team, this proved unnecessary, as the weighted master template already was able to provide emergent behaviors that reacted intelligently to player stats.
It all factors in to the way the AI plays…And it’s not just the players who have improved, as the teams finally play more like their real-life counterparts as well. Play against the Heat and watch as Shaq dominates the paint…and the results dramatically improve the experience, not to mention, the more sim-like feel.
https://www.ign.com/articles/2004/09/27/nba-live-2005
Overall, the new system only required 1/3 the processor time per second of the legacy system. Also, because the new system evaluated every rule, every time, it was extremely consistent in processor load, as opposed to the legacy system which suffered from occasional processor spikes.
While the system stepped up the game for the highest rated NBA Live entry, it did come with a few drawbacks that had to be addressed along the way. The most noticeable of these was problematic edge cases. Almost a third of the rules that were added to the dataset were merely to manage edge cases (buzzer beaters, bad positioning, etc) and new edge cases continued to appear even late into alpha. However, edge cases are always an issue and not an inherent design flaw to this approach.
Ultimately, NBA Live 2005 benefited tremendously by the refactoring of the legacy black box AI into a dynamic, data driven state machine.
Code Samples from Hobby Games
Timeline of Primary Code Languages
- 1999 – 2004: C/C++
- 2008 – 2010: C# (XNA)
- 2010 – 2011: Objective-C
- 2012 – 2014: C++
- 2014 – 2015: C# (Unity)
- 2019 – 2021: Tales Script
An early influence on my programming fundamentals was Scott Meyers’s Effective C++ series.
Initially my design approach was heavily IS-A (inheritance) focused. In 2009 I grew to rely more on HAS-AN (aggregate) forms, and finally, in 2014 Unity honed my HAS-A (composition).
My earliest endeavors into Hobby Game development was with Microsoft’s XNA framework, which was later rebranded to Xbox Indie Games.
While none of these games in of themselves were particularly notable, the amount of learning that went into creating the engine to power them was substantial.
Working with XNA in the early days wasn’t quite what it is today (no Game Studio for one). It can best be described as a managed wrapper on top of DirectX. It handled a lot of the low-level code, like memory management, sprite batching, and polygon rendering, but it didn’t handle things like complex visibility and rendering passes.
Check out the LitObject Visibility code on GitHub: LitObject.cs
The entire engine (but not the games) is on GitHub, but it hasn’t been run in years, and probably won’t compile against current XNA libraries. GitHub: ChiseDrive
Later, I converted to working in Unity for hobby projects. The overall quality increased with an engine doing the heavy lifting so I could focus on gameplay and art. However, as a side effect of this, the code samples aren’t nearly as compelling!