T w e n t y S i d e d

At the beginning of a project there’s always a big burst of progress. Every ten minutes you’ve got another feature or another improvement, and it’s easy to delude yourself into thinking you’re John Carmack. But then you enter the middle phase of the project and suddenly it’s time to tidy things up, get your interfaces in order, and work on some of the boring, non-sexy stuff.

So that’s where I am right now. Sooner or later I need to do the Great Big Post About Gameplay Mechanics, but I keep putting that one off. Up until now this game has been all things to all people. Everyone can look at these screenshots and fantasize about all the ways it could be exactly what they wish. Everyone can look at it an scream, “Shut up and take my money!” because so far they haven’t seen anything that indicates it’s not something they would like. When I finally get around to nailing things down I’ll end up breaking some hearts, and I’m not quite ready for that trial yet.

So let’s dig through funny screenshots.

Continue reading ⟩⟩ “Project Good Robot 14: Outtakes”

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.

I’ve been reading back over this series, and I have to say I’m pretty happy at how far we’ve come in such a short time. But I have to admit the one thing we need more of in this write-up is crappy MS-Paint level illustrations. So let’s fix that.

We start with our flying robot:

Pfft. I have no idea why people waste money on artists making concept sketches. I think this looks awesome already! In fact, we could throw a little lens flare on that thing and we’d be ready to start taking pre-orders.

As cool as this is, I think it would look even more amazing with a leg. Maybe even more than one leg. But we’ll start with one. The first step is to pick a horizontal offset from the body. Let’s say we draw a line that extends one unit to the left of the body. This creates a point which we will call the knee. The knee can move up and down, but it always has to stay the same distance from the body horizontally. (Yes, I could have the knee pivot instead of moving up and down, which would be more “correct”. But I’m going for an effect here.)

Continue reading ⟩⟩ “Project Good Robot 13: How Do We Leg?”

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.

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.