Heroes of Newerth

Heroes of Newerth (HoN) is a popular Multiplayer Online Battle Arena (MOBA) played by players around the world. HoN is generally played with 2 teams of 5 players facing off in ‘tug-of-war’ style gameplay. Each team’s goal is to try and push into the other team’s base and destroy it in order to win. Players control heroes with unique abilities and stats that grow stronger as they defeat players on the other team and other non-player enemies.

Plinko was a feature added to HoN as a new form of monetization for the game. The goal was to create a system where players could spend in-game currency (gold) to get a random prize (which could potentially have more value than the gold spent on playing); Plinko specifically was selected because it is not related to gambling (which would be an undesirable association). When working on plinko I worked closely with HoN’s web team to figure out the requests needed to get the system working. Aside from web work, all of the technical work for plinko is done in the UI using Lua (no C++ directly related to plinko was required) and was written by me. Everything said and done, plinko works by sending a request to web for a plinko drop (which is comparable to purchasing a product) and then playing back a pre-generated path for what tier they got and presenting the prize to the user. A lot of time was spent trying to figure out how to guarantee the outcome of a game of plinko and pre-generated paths ended up being the nicest solution for multiple reasons.

I have added a lot of different gameplay features to HoN, some of these features are more impactful than others; Instead of including a bunch of different sections with interesting gameplay features I will use one section to list a few of the more interesting things I have implemented.

Gameplay in HoN runs through a series of phases (called game phases) such as pre-match, in-game, game-ended, and more. I added a new phase, at the request of designers, that sits between in-game and game-ended. This phase is called ‘post-match’ and is usually used for any extra events that occur on a map after the game is over. During the post-match phase players are free to leave the match without penalty however, unlike the game-ended phase, gameplay logic is still ran (though a winner has already been decided at this point). Designers have utilized this game phase to add things such as celebrations for the winning team after a match is over or other small cinematics.

Another gameplay feature that I worked on adding was player and team scores (player scores already existed to an extent but I finished the implementation and made use of the scores). Goals for these scores can be set by gameplay scripting; This allows creating maps/game modes that require teams/players to reach certain point values before winning the game. Score goals can also be set to not end the game but indicate to scripting when the goal is reached; This feature is used for maps/modes where certain events happen when the goal is reached such as the players on the enemy team no longer respawning.

The final gameplay feature I will discuss that I implemented is rounds. Rounds can be used by scripting in various ways to create gameplay that is split into a series of separate rounds. Each round is split into 3 main phases: pre-round, mid-round, and post-round. There is also a 4th phase called round-ended to indicate that the round is over and the next one has not yet begun. The three main round phases can be given a time limit (in which case their timer counts down) or they can be set to run forever (in which case their timer counts up). Rounds phases will advance automatically when their time runs out or they can be advanced manually by script; If script advances the round phase after the last round has ended it will move into the next round. Rounds cannot be used to create victory conditions for a map/game mode but script events are ran each time a round phase begins/ends and scripting can access the current round number; These events and the provided information is more than enough for scripting to setup their own victory conditions and create interesting round based gameplay.

HoN has had a public map editor for a long time (and it’s the same tool that is used internally to create maps). However, this editor had been missing one major feature: undo and redo functionality. Much to the delight of the people who make use of the map editor (mostly people on HoN’s design team) I added this functionality to HoN’s map editor. To put the implementation very basically, this was accomplished by having each tool that can be used to edit the map generate a “tool change” after making a change. The editor keeps a list of these tool changes (and prunes that list when needed) and undoes/redoes changes by calling the undo/apply functions implemented by these changes; The large majority of these changes simply keep a buffer of whatever the data we changed use to be and then a buffer of what the new data is. On undo it copies the old data back and on apply it copies the new data.

Along with adding undo/redo functionality to the map editor I fixed various bugs and added a couple of quality of life improvements to the map editor. To help visualize the sounds on each map I added visual fall-off indicators for our sound effects. I fixed a bug that was preventing sounds on the map from actually playing in the editor. I also fixed a couple of nasty memory corruption bugs with the water tool. There were a handful of memory leaks in a couple of different tools. The foliage tool was unable to be used past certain points on maps because they were incorrectly bounds checking themselves. The water tool could not actually display changes to the water without reloading the map. There were multiple crashes caused by loading new maps because some tools kept their selections from the previous map. And much, much more; The editor still has its share of issues and occasional crashes, but its functionality and stability have been massively improved.

Render target textures are one of the latest features for HoN that I worked on. HoN has a resource management system that tracks loaded textures and is used when rendering to look-up and access textures. The goal with this functionality was to create a system that would allow us to render to a texture (for example, rendering a dynamic string of text) and then later using that texture somewhere in the normal 3D scene; This was a bit tricky to accomplish as while we do render to targets other than the back buffer from time to time, this behavior has always existed down in HoN’s graphics libraries (where-as this needs to exist at a higher level than that). Implementing this required adding a new extended type of texture that could be passed down into the graphics libraries and set as render targets; Also, because it was created by extending the original texture functionality, the rest of the engine could use this textures like a normal texture and render it as needed. Along with creating the new type of texture I had to extend our video API to allow creating render targets, setting them as the active render target, restoring the old render target, etc. Finally, after extending our video API to include these functions, they had to be actually implemented for both the DirectX and OpenGL graphics libraries.