Category: Development

Categories
Development

BattleGrid Music

I’ve written in many posts about how much I’ve been dreading working on the music for BattleGrid. It’s something I’d like to learn, but I simply have no skill when it comes to music. Unity has been running an “Asset Store Madness” sale this month, and I picked up a “Retro SFX” pack for half price. Some of the sounds in the pack are similar to some I had created using a simple, free tool I found, but were a better quality, so I’ve started using them where they’re better than what I had.

After using the sound effects, I thought, “Hey, maybe there’s music available, too.” So I did some searching and it turns out there’s some very good music on the asset store. I had to wade through tons of music that wasn’t great or didn’t fit the style of BattleGrid, but a few things I found are perfect – almost exactly what I had in my head but could never reproduce in reality.

Even better, as this is an asset store for a game development platform, several of the tracks are designed to be looped or have sections that can be looped, making it easy to make use of the tracks within a game. And the licenses are appropriately flexible, as well: royalty-free use in practically anything as long as the tracks aren’t able to be redistributed.

Categories
Development

I think this sums up why I like programming games.

public enum DamageType
{
    /// <summary>
    /// Average, everyday damage.
    /// </summary>
    None,
    /// <summary>
    /// PEW PEW PEW
    /// </summary>
    Energy,
    /// <summary>
    /// BOOM!
    /// </summary>
    Explosive,
    /// <summary>
    /// HULK SMASH!
    /// </summary>
    Kinetic,
    /// <summary>
    /// You shall not pass!
    /// </summary>
    Magic,
}

What should I add?

Categories
Development

There’s always more to learn…

One of the reasons I love programming is that there is always something new to learn – a new language, a new technology, a new technique. The bright side is that it’s always fresh and fun. The downside is that sometimes it makes you feel like an idiot.

I’m going through this “new and exciting” experience with my game. Unity is a fantastic development platform – it’s flexible, it’s easy, and it’s powerful. I’ve been working with it for over 2 years now, so I thought I had figured a good bit out about how to do things. But I’ve been struggling with getting a decent frame rate even though my game is really pretty basic. My game has tiny worlds (minuscule, really), mostly static meshes, low-poly models, etc. However, the frame rate would frequently dip below 30 FPS… Totally unacceptable on my fairly beefy computer.

Now, a lot of my problems are just the result of a misunderstanding about how Unity optimizes some things. Unity uses an “Update” method on objects that need to be updated every frame. I was using this method all over the place to manage things that needed to happen over time – but not necessarily every frame. Well, as it turns out, having that Update method means Unity needs to call that method, which takes time, even if the method doesn’t do anything. So, I went back and stripped out most of my “Update” methods and replaced them with coroutines. And instantly I got a 20-30 FPS increase.

But my frame rate was still sitting in the mid-50s for a simple game. I’ve spent hours tweaking some of my most commonly used code to eke every last drop of performance out of it. I’ve done a pretty good job, and created a lot of code that’s useful for time-slicing and scheduling operations to run over multiple frames. Still not enough, though.

So today I’m doing some thinking and out of nowhere, an idea pops into my head: “What if I try triggers for targeting?” A trigger in Unity is a collider that doesn’t affect physics. So, it can tell when another object enters, moves around within, or leaves its collider. You could use them to trigger an enemy spawn when the player gets close, or fire a trap, or whatever. Stupidly, I had not been using them for targeting. Instead, I was periodically scanning every target within range and finding the best target. With triggers, I can instead handle this as new targets come into range – when a new target comes into range, check to see if it’s “better” than the current target. This has two side effects: it’s doesn’t take as long because you’re only checking a single target, and it happens as soon as the target enters range. This means that turrets will now immediately notice a new target and react to it instead of having to wait for the next target scan.

Luckily, my AI design was pretty good, so making the switch was easy and I got it tested within an hour. My frame rate is now sitting in the 100+ range, though I still want to try it out on a really busy battle. If things work out, I won’t have to go to some of the “drastic” measures I was thinking about (like enforcing a unit limit).

Categories
Development

Game Development

So over the course of developing BattleGrid, I’ve learned a lot about game development – nitty gritty stuff that it’s hard to learn without actually doing any of the work. I find a lot of this fascinating. I develop applications for a living, and while the basics are all the same, the details about how to do certain things are totally different. Case in point:

I don’t care how quick it is, split it up over multiple frames
There are a lot of things that I could do with a single line of code. I’m a bit of a code snob – I love clean, elegant code that’s easy to read, understand, and maintain. (I have a coworker that doesn’t feel the same way. We don’t get along.) In game development, though, you sometimes have to take a single unit of work and split it up over multiple frames. This means doing a bit of extra work to keep track of your progress each frame, so you can continue on the next frame. There are elegant ways to do this (I think I have a decent method), but it will never be as nice as the one-line beauty that I had before.

An example would probably help. Take targeting. Each turret and unit in BattleGrid has a targeting component that picks out the best target on the map. I’ve simply defined “best” as “closest”, so we just need to do a range check to find the closest. When I started, I just did the work, something like:

public void FindTarget()
{
    var target = this.Targeting.FindClosestTarget();
    this.SetTarget(target);
}

This worked great, except when an enemy was destroyed and the 5 turrets targeting it all decided to find new targets. Finding a target for an individual turret was easy and quick enough to do in a single frame, but if too many turrets all tried to find a target at the same time, the game starts to chug. So, I developed a simple queue:

TaskQueue.Enqueue(this.FindTarget);

Without going into any detail about what that means, that just puts the “FindTarget” action onto the task queue. The task queue executes one operation every tick (about 1/60th of a second), so if 5 turrets need targets, they just queue up their “FindTarget” actions, and targets are found over the next 5 ticks. This is fast enough that a player never notices, but slow enough that it doesn’t hurt framerate.

All this talk about targeting loosely relates to my next point:

AI is hard, but rewarding
I’ve never had kids, but I imagine teaching a kid to do something and then seeing them do it gives about the same warm fuzzy feeling that seeing an AI do what you taught it gives me. I’ve done a lot of work on the AI in BattleGrid, and I know there’s still plenty to be done. One of the hardest things to figure out was how to “teach” the AI what to build in given situations. I had a few ideas that were really complex, but ended up with a pretty simple idea – give the AI “effectiveness” values to work with.

This is what players do without thinking too much about it. “Oh, that guy has a blaster turret protecting his base. Missile turrets are longer range and can destroy that turret easily. I’ll build a missile turret.” I stored “effectiveness” values for every structure in the game. For instance, I’ve set it up so blaster turrets are highly effective against all mobile units, and artillery is effective against all stationary structures.

Now, I knew I had set these values and taught the AI how to use them. Even knowing that, the first time I saw an AI build a missile turret just out of range of one of my blaster turrets, I was amazed. That’s something a player would do – build a longer-range turret out of range of the shorter-range turret.

I’m still amazed when I see the AI counter my structures with the same things I would. I build artillery, they build shields and tanks. I build tanks, they build blasters. It’s the standard rock-paper-scissors scenario, but it’s fun to see it in action.

Continuing on AI…

Sometimes the AI needs to cheat
One of the things I noticed while playing is that the AI is much more difficult when it can afford more. When I dropped the price of all the structures (for testing), the AI could more effectively counter anything I did because they had the cash to do it. So, for more difficult AI settings, the AI cheats a bit… They get twice as much income as the player. This gives them significantly more cash, which means they’re not only thinking faster, they’re also building more that the player has to fight through. Fortunately, the AI isn’t particularly devious or clever, so the player can still beat them, but it takes significantly more work, which is exactly what I wanted for more difficult AI.

Balance is hard
I’ve struggled to get everything to feel balanced. The more options you give a player, the more difficult it is to make sure those options are balanced. I want BattleGrid to support multiple styles of play and make them all viable (playing offensively or defensively), but that makes it incredibly difficult to make sure each play style gets a fair shake. I don’t really have a solution here; it just takes a lot of testing and tweaking.

There are many more examples, but this is enough for now. Hopefully over time I’ll start to find elegant ways to solve all these problems; ways that I can carry forward into other projects.

Categories
Development

I think I’m a code snob.

I work with a small team of developers – there’s about seven of us in total that do full-time development. Of that group, there’s only a few of us – about three – that I would call “serious” about coding – by which I mean would have heated and/or deep conversations about “good” code. Of those three, two of us typically feel about the same, and the third doesn’t really agree.

If it’s not already obvious by the wording of that last sentence, I’m in the two-person group. The two of us have pretty similar ideas on how to write good code. Here are some of the principles we try to follow:

YAGNI (You Ain’t Gonna Need It)
I heard a variant of this in college that went “Lazy programmers are good programmers”. The idea here is: don’t write code you don’t need. This obviously varies a bit depending on what you’re writing, but in general, just don’t create anything until you need it to exist. We work in a teeny team and all our development is for internal projects. It’s a giant waste of time to try to create a perfect solution that will fit everybody’s needs, especially when you don’t know what those needs are.

Don’t Reinvent the Wheel
If you run into a big, general problem, someone else has probably solved it, and has done a better job than you will. I don’t care how good you are, you’re not going to sit down one day and turn computer science on its head. You’re not going to sit down one afternoon and crank out a better solution than a several-hundred-man-hour open source project. So don’t think you’re right and they’re wrong because they don’t do something the exact way you want. Instead, just benefit from the hundreds of hours of work and expertise that has gone into creating something ahead of you.

We All Write Bad Code
Everyone has written crappy code at some point, so when someone calls you out on it, just accept it and move on. I have a hard time with this one myself, since my instinct is to fiercely defend any assault on my code as if you’re trying to eat my baby. But there have been plenty of times I go back and look at my code and say, “what was I thinking?!”

Be Open Minded
There’s always something new to learn as a developer – it’s why I love my job. There will always be a new technique, a new language, or a new style out there. It’s important not to get set in a particular at of doing things.

Now, it’s time for me to rag on person number 3…

I’ve gotten into arguments about code at work before. It hasn’t happened lately (mainly because I haven’t had to work with that particular person), but it still bugs me. After putting a lot of thought into it, I think I’ve settled on the fact that I’m a bit of a snob when it comes to code. Be warned, I’m about to do a lot of patting myself on the back.

Plenty of people can write code. Writing code to make a computer do things is not hard. It’s a science – there’s a good bit of learning, sure, but once you know the language, you can do all sorts of things.

I think what makes a good programmer is art. There’s a difference between getting the job done and writing good code. Good code is clean, simple, and elegant.

I code in C#. I absolutely love it. It’s a wonderful language, and anyone who thinks otherwise obviously hasn’t spent much time with it. However, a lot of the greatness behind C# is in the work Microsoft has done on the .NET framework to add tons of code to make my life easier.

LINQ
I think LINQ is God’s gift to programmers. It’s simple, it’s clean, it’s powerful, and it’s easy to understand. I do a lot of data analysis-style work. That means taking a bunch of data and processing it to get more data. Let’s take a simple example of calculating the average for a set of data points.

[csharp title=”Old-School”]
float total = 0;
foreach(float value in data)
{
total += value;
}
float average = total / data.Count;
[/csharp]
Now, that’s not complicated. Any programmer can read and understand that. It’s not technically wrong. However, I’d argue it’s not good, especially when you have this alternative:

[csharp title=”LINQ”]
data.Average();
[/csharp]
I’m fairly certain someone who is not a programmer can understand that. Why wouldn’t you use that if you had it at your disposal?

Now, that’s actually a LINQ extension method. I prefer the extension methods to actual LINQ syntax, but they’re both great. Actual LINQ syntax is a lot like SQL:
[csharp]
var points = from x in xValues
from y in yValues
select new Point(x, y);
[/csharp]

It’d be easy to wrap your “average” code in a simple static method in a utility class and use it wherever you wanted. The power in LINQ comes from being able to chain things together. For example:
[csharp]
var moreData = points.Where(p => p.y > 20).Select(p => p.x).Average();
[/csharp]

OK, we’ve gone back into programmer-only town. But if you know LINQ (or maybe just C#), you can see that means you’re taking the points where y is greater than 20, selecting their x values, and averaging them. Even without knowing what it all means, you can start to get an idea of what’s going on – you’ve got points, and where something is true, you’re selecting something, then averaging it. It’s a natural way to think about the data.

Extension Methods
C# has a feature called “extension methods”. As the name implies, these are methods that extend another object. These are extremely handy when you don’t control the object in question. For instance, say you want to add some functionality to an object created by Microsoft. With an extension method, you can add that functionality.

You could always write the method as a static method on a utility class:
[csharp]
Utility.DoSomething(myObject);
[/csharp]

This is fine, and gets the job done. But with a very minor change to the “DoSomething” method, you can also use it like so:
[csharp]
myObject.DoSomething();
[/csharp]

Of course, this may not always be appropriate, but I find it often produces more readable code. The other benefit is with IntelliSense, where once you’ve typed myObject., a list of what you can do appears.

I’ve heard it said you should use extension methods sparingly, and that’s absolutely true. Some things just don’t make sense as extension methods. However, I’ve found they often make my code look better and read better, and if you’re using LINQ, they can fit in with the LINQ methods beautifully.