Wizgun’s visuals are a hybrid of 2D and 3D objects. The characters are all 2D planes animated with Spine, whereas the environment is composed of 3D meshes. Many of the particle effects are 2D flipbooks. Most of our ground is a 2D tilemap, but the cliffs below the ground are 3D.
Unity allows a lot of flexibility in how you structure visuals, which is nice for authoring, but a pain for implementation. Our artists and designers consistently put together great looking assets, but it fell to the engineering team to pull it all together into a cohesive art pipeline. It ended up being an extremely iterative process where we’d fix one bug, only to discover another, and fix it, and discover another, ad nauseum, until everything looked good enough.
This article is a list of every single technique, trick, and outright hack that we used to get 2D and 3D objects to play nice.
Creating a networked multiplayer game with only three full-time engineers was extremely difficult. One of the largest challenges we faced was solving state divergences. In this article, I’ll go over what a state divergence is, and how we managed to track down the majority of our divergences before launch.
I’ve tried to abstract away Wizgun’s specific architecture as much as possible, but I go into specifics where necessary. It will help if you are already familiar with networking and deterministic lockstep. If you are in development and trying to solve the same kinds of problems, this info is for you. I don’t want anyone else to have go through the pain that we did.
I was largely responsible for all of the technical art on the project. This article is about the water shaders that I created. I was tasked with implementing the style in this piece of concept art:
I’m Ed Lu, principal engineer on Wizard with a Gun, which released on October 2023. There’s tons of work I’m really proud to show off, and I’m writing a series of articles to just that. I’ll kick off the start of this series by breaking down our method of rendering ground tiles.
I was largely responsible for all of the technical art on the project. This is the piece of environment concept art I was working from:
There are two particular parts to this concept that I will cover in this article. We call them “tile skirts” and “tile cliffs.” Let’s start with skirts.
Since November of 2019, Nick Amlag and I formed a video game studio and shipped Breakpoint, a twin-stick action game with exploding melee weapons. It released pretty recently, so go check it out!
Breakpoint is an arcade game centered around chasing high scores. The leaderboard is centrally important, providing players the reason to play the game - to better their own scores, and to surpass others. The sanctity of the leaderboards is critical to ensuring that players feel that the game is fair. If cheaters begin showing up on the leaderboard, confidence erodes, and players feel that there’s no point in chasing high scores of their own.
The in-game replay system is our solution to this problem. Replays ensure fairness by allowing any player to check the validity of another player’s scores. Simply by clicking on another player’s name, they can instantly start watching the replay of that player’s high score run.
Since November of 2019, Nick Amlag and I formed a video game studio and shipped Breakpoint, a twin-stick action game with exploding melee weapons. It released pretty recently, so go check it out!
For those unfamiliar with Breakpoint, a core mechanic of the game is managing your weapon’s durability. The amount of durability remaining is indicated by the circle around the player. Hitting enemies with your weapon depletes its durability, and when all of it is gone the weapon breaks, unleashing a large explosion. The size of the explosion depends on the level of your weapon when it breaks.
Since it’s such a central mechanic, a lot of intentional design went into creating the explosions. Not only will I show how we make that explosion look awesome, but I’ll also discuss how the visuals contribute to readability of the game mechanics.
#devtober day 3: Polished up the elite affix system. Fixed a bunch of bugs and added art. It's looking pretty good! Still unbalanced, but I think I'll leave it as-is for now. pic.twitter.com/7GFJA4o8S0
This past October, I participated in Devtober. You can take a look at their website for more information, but to summarize: it’s a game development challenge where you work on your game every day for one month, then write up a postmortem about what you learned.
Devtober also happened to coincide with me going full-time indie! I’ve been self-employed since Sept. 16th. Devtober actually didn’t change much how I work on games - I’ve been trying to work a little bit every day for a while - but going full-time certainly did.
Because of that, Devtober ended up being a bit of a different experience for me than for others. That’s not to say it was a disappointment, though! Below are some of the highlights and problems I faced during the month.
It’s a truism of software development in general that systems in production tend to have a lot of inertia. Want to change something after it’s in use? Better prepare for a lot of pain.
Such is the way with data migrations, and in this, Unity is no exception. It appears that the only official tool that Unity gives us the FormerlySerializedAs attribute, which handles renames of fields.
This attribute is indeed quite handy, but what if you’re doing more than a rename? In this post, I’ll outline the general framework I use for non-trivial migrations. I’ll warn you - it’s not pretty, but it works.
I’ve had the great pleasure of working with an artist/designer on Obelus. It’s been a blast seeing how they approach problems differently, and how many awesome ideas they have that I’d never have come up with. As the sole programmer on the project, I’ve been putting together a bunch of tools for the designer to use.
While the Unity Editor gives me lots of power to put together tools, as a programmer I still have to define the architecture of how the solution works under the hood. In this article, I’ll outline my solution for putting together status effects, as well as a more general pattern which can be used for solving similar problems.
Note that this article assumes a fair amount of knowledge of C# and Unity, specifically ScriptableObjects.
This is the third post in a series about the tech we used to put together Rift Core. If you aren’t familiar with Rift Core, you can check it out here. It’s an action RTS game about a squad of mechs who are desperately trying to save their world.
In this post, I’ll cover one of the more elaborate VFX we built for Rift Core: the shield. There’s several components in the shield effect which all add up to the final result. I’ll cover each one in detail.
