T w e n t y S i d e d

Games are a young medium, and we’re still inventing (or appropriating) nomenclature for it. Ludonarrative Dissonance, Kinesthetics, skinner box, gamification, consolification, boss fight, quicktime event, RPG, difficulty curve, level scaling, HOTs and DOTs, raid, crowd control, pay-to-win, force feedback. Twenty years ago these terms either didn’t exist, or they meant something else to the average person. Some of these terms came from the audience, and some of them came from game designers, but they all arose out of a need to talk about a thing that didn’t have a name yet.

One concept I’ve needed a word for is the way games use multiple audio / visual cues to let you know that a thing happened. The term I’ve settled into was “feedback channels”. But lots of people have run into this concept long before I showed up, and they already had their own terms. These two guys call it “juice” or making a game “juicy”:

Continue reading ⟩⟩ “Project Good Robot 12: Feedback Channels”

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.

A running theme of this project is that 2D game development is like programming in Easy Mode. Everything takes less code, requires fewer steps, uses less CPU / memory, and has a larger margin for error. It’s amazing to be able to just make something without constantly getting snagged on annoying tech issues, performance trade-offs, and gameplay compromises.

Take collision detection, for example.

Early in the project I used rectangle-based collision. If I shot at a bad robot, the game would check for a collision between the bullet and the square region where it was drawing the enemy.

Okay, pixels don’t suffer zooming nearly as gracefully as polygons. Then again, you can fix this by just not letting the player zoom in too far. Good luck keeping the player from looking at the walls too closely in your FPS.

But this is a crappy solution. Basically every enemy is shaped like a box for the purposes of collision. That’s good enough when shots hit center-mass, but it’s really unsatisfying to have bullets score a hit when they pass through the (usually empty) corners of the rectangle. Unless I’m going to make all the foes square, this isn’t a viable technique.

So I change it to check using distance calculations:

Continue reading ⟩⟩ “Project Good Robot 11: When Stuff Collides”

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.

Sometimes people ask me what the difference is between a programmer and a software engineer, and my usual flippant answer is that software engineers are what programmers call themselves when they want to sound important. But that’s not entirely fair and often the distinction is worth making.

Metaphorically, software engineering is designing a bridge that won’t fall over, and programming is the act of rolling up your sleeves and laying bricks or nailing boards together to make the bridge a reality. It’s easy to see the difference between the two disciplines when we talk about it in terms of construction, because you’ve usually got two very different kinds of people doing those jobs. The designer does her thing, then the builder does his, and the next thing you know you’ve got a bridge. But when you’re building software the same person is most likely doing both jobs, and they’re most likely doing them at the same time.

Perhaps it sounds foolhardy to design a bridge while you build it. Joel Spolsky will tell you that you should design the bridge before anyone starts putting bricks on top of each other. And for the most part that’s true. Without good engineering you’ll either end up with ungainly code, or you end up doing lots of rewrites.

But you can’t write a spec if you don’t know what what you want to build or how you want to build it. This isn’t a bridge-building project, this is a skunkworks. We’re looking for fun gameplay and you can’t really appraise the fun of something until you’ve got a working prototype.

So we’re coding with no spec. This leads to interesting problems.

Continue reading ⟩⟩ “Project Good Robot 10: Software Engineering”

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.

My project depends on a number of external libraries. It wouldn’t be possible to get this much done without offloading some of the drudgery to a few low-level packages written by others. I can make windows without getting married to Microsoft, render polygons without worrying myself with the arcane details of the driver layer, and make sound effects while knowing not a blessed thing about audio hardware.

The downside of not writing your code yourself is that you’re dependent on other teams, who might not be all that dependable. A few people have asked what libraries I’m using. So here it is:

Continue reading ⟩⟩ “Project Good Robot Part 9: Under The Hood”

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.