Blog - Page 3 of 16 - Pyrodactyl Games

Good Robot #42.75: Pro Strats

March 7, 2016 · Arvind

Originally written by Rutskarn on Shamus’ Good Robot Devblog

“There’s something you can do to help get the game ready to ship,” said Arvind over Hangouts.

“What do you mean, ‘ready to ship?’ It launches in a few weeks. I finished the script, like, hours ago. What’s left?”

“Playtesting. How many hours have you been playing?”

“Aw, jeez.” I checked my counter. “About 75 hours this week?”

“Are you serious?”

“Yeah, sometimes fourteen hours at a time. I’m playing right now. I’m sorta waiting for you to hang up so I can go back to talking to it like we’re friends.”

“And have you found any bugs?”

“I don’t know if I’d call it a bug, but Vaegir Guards are just the worst. They’re like drunk dumpster gnomes on drunk ponies. How’s a girl gonna conquer Calradia with a horde of these chumps?”

Continue reading →

Good Robot #42.5: Good Writebot, or How to Write a Videogame Story in 25 Easy Steps

February 22, 2016 · Arvind

Originally written by Rutskarn on Shamus’ Good Robot Devblog

I hope you’ve all been enjoying Shamus’ series on the art of programming, which I understand is writing special words that make games happen. Sometimes you don’t write the words good enough and the game isn’t good; John Romero did this one time and he’s been working as a garbage man in Tulsa ever since. I’m the lead writer, so programming isn’t really my department, but having accidentally opened the source code while Arvind was explaining TortoiseHg again I can see why Shamus has been having so many problems–to be frank, the grammar was terrible and almost three quarters of the words were misspelled. I did an editing pass which I assume fixed most of the problems; Shamus has assured me this will be the topic of posts #43-129.

But I think we’ve all got the basic idea: coding is “hard” and “interesting” and “requires technical skill” and “can be objectively assessed.” But is it really the most fundamental part of a videogame? Shamus and Arvind say “yes,” repeatedly, at progressively louder volumes–but I’m not convinced. If you take away the code I’m sure a videogame will still run, but can you say the same about its story? What would Killzone, Rocket League, and Neko Atsume be without their rich internationally beloved canons? And if it wasn’t for Final Fantasy villains, how would you know which of your old forum accounts to be slightly embarrassed by?

My point is that my job writing Good Robot (or more precisely, writing a couple hundred headlines that display when interacting with vendors, plus some names to go with level bosses) is exactly as critical as the stuff Arvind and Shamus do all week. I’m guessing. They keep forgetting to tell me when their meetings are.

So in the vein of the rest of this series, here’s a few days in the life of the Lead Writer (!).

Continue reading →

Good Robot #42: The Framerate Unleashed

February 11, 2016 · Arvind

Reposted from Shamus’ Good Robot Devblog

Good Robot has a problem. It’s a strange, goofy, inexplicable problem and I’m pretty sure (60%-ish) that it’s not my fault. Here is what’s up:

Our game is capped at 60fps. That’s fine, except the cap isn’t self-imposed. Oh, I have a frame-limiter in the game, but it doesn’t do anything. If I disable it, the game is still limited to 60fps. Even if I render nothing more than a blank screen, I can’t get the framerate to go above 60. Under those conditions, the framerate should be in the thousands.

Please enjoy this animated gif, which is NOT REMOTELY running at 60fps!

Continue reading →

Oh Gosh! It’s a Good Robot GIF Gallery!

February 1, 2016 · Arvind

Check out these bits of Good Robot gameplay footage in animated GIF form. Some of them might take a few seconds to load, but it’ll be worth it!
Continue reading →

Good Robot #41 – Why Promote Your Game?

January 27, 2016 · Arvind

Good Robot is almost done, and we are on course to finish the remaining tasks in the next couple of weeks. We’ll release the game in the first week of April, which should give us some breathing room for testing and polish.

However, there is another reason we are launching the game two months after we’re done making it – promotion. This is the part where you email every single Game Journalist / YouTube Personality / Twitch Streamer / Person with a Blog in an illegal-substance-fueled-frenzy and hope they play your game and tell others about it.

You have to cover our game! It has an exploding Frisbee that bounces off walls in it!

“Why do you need to promote your game, Arvind?” I hear my friend Manny Straw exclaim, “If your game is any good, surely you can just put it up on Steam and people who see it will tell their friends about it, and then those friends will tell their friends, and soon you’ll sell a million copies! That’s how Minecraft did it!”

Continue reading →

Good Robot #40: Overdraw

December 30, 2015 · Arvind

Reposted from Shamus’ Good Robot Devblog

My to-do list grows and shrinks as the project rolls on. I’ll have 20 items on my to-do list one week. I’ll get 13 of them done. Then at our next weekly meeting, those 13 are reviewed. Some are marked as done. Some end up back on the list because my solution was too narrow, or didn’t work in all cases, or I misunderstood the problem. Then a few new issues will get piled onto the list.

So after the meeting my to-do list will be back up to 25 or so items and we’ll begin again. So it goes.

But some items have never been touched. They’ve haunted the bottom of the list, never getting done, never getting looked at. The oldest item on my list now is actually a collection of bullet-points that can all roughly be summed up as “performance problems”. To wit: The game runs too slow.

Not on my machine, mind you. It’s fine on my machine. But on craptops (i.e. really old/slow computers) it runs at about half the framerate it should. So what’s going on?

Continue reading →

Good Robot #39: Teaching Players to Play

December 2, 2015 · Arvind

Reposted from Shamus’ Good Robot Devblog

Some other indie developers were nice enough to play the game and send us their feedback. A common theme in the feedback was that things were too chaotic. Or too random. Or unfocused. Or too busy.

Looking at the game, it’s easy to see why, and it’s easy to see how we slipped into this state. We made a system that let you make wildly divergent robots, simply by tweaking a text file. Since creating robots is easy and variety is good, then more robot types = more good, right? Aren’t games always bragging about how many enemy types they have? Isn’t this a selling point? “Fight over 12 different enemy types!” it says on the back of the box.

Only 12, AAA game? Pshaw. We have that many in the first 15 minutes of the game!

It made sense at the time, but when the feedback rolled in it was a forehead-slapping moment for all of us. Of course this will seem like random chaos to someone who hasn’t played the game constantly for 6 months.

It’s like a version of Half-Life 2 where your first fight is against a group of foes with the behaviors of an antlion, a zombie, two soldiers, a metrocop, a strider, and a gunship. It’s not about being “too hard”, really. Even if you lower the hitpoints and damage output on the gunship and the strider to bring them into line with (say) a metrocop, the player still can’t be expected to parse all this chaos. They’re not going to appreciate the differences between the soldier and the zombie when both foes die in the same panicked volley of weapons fire.

Continue reading →

Good Robot #38: Spec’ing a Feature

November 25, 2015 · Arvind

(Shamelessly reposted from Shamus’s Good Robot Devblog)

When you’ve got more than one person working on a complex bit of software, you generally need a specification (spec) for new features. The bigger the team, the more you need a spec. The more complex a feature, the more you need a spec.

According to stereotypes, big firms usually lean too hard on specs, to the point where they might spend more time writing the specs than coding the feature:

“The button will be ten pixels from the left margin and will conform to the usability guidelines sheet 201-a. It will be labeled “Join Game” and will – after a confirmation popup as outlined in the interface framework – begin polling the designated server in request for an open slot. If no slot is found, then the fallback behavior […]”

Meanwhile, little indie houses have a slightly less formal approach:

Bruce: Can you add a button that will let players join the game? Barbara: Sure.

Stuff gets done either way, but sometimes indies are a little slapdash and sometimes big firms are a little too bureaucratic. On Good Robot, our spec is usually a sentence or two in the shared Google doc that we use as a universal to-do list.

But this week I ran into something that I realized was too complicated for that. It was one of those features that sounded obvious and simple in the meeting, but then became mysterious when I sat down to write the damn thing. (This is the point of a spec: To reveal the unknowns BEFORE coding begins. This is important in big firms, since once you’ve begun coding you’ve ALREADY been allotted a fixed time budget, which means this is a bad time to begin figuring out what you need to do.)

Continue reading →

Good Robot #37: Get Things Moving

November 9, 2015 · Arvind

Reposted from Shamus’ Good Robot Devblog.

Let’s talk about little things that make a big difference.

The game was lacking something. It was just too static. The world didn’t move, didn’t animate, didn’t react. The screenshots looked good, but when you were playing the game it felt like you were flying past a painting or something.

So my first solution is dust particles. Here is a shot of them, zoomed in so everything looks terrible:

Good Robot 2 will feature a multi-pass hypo-allergenic dust diffusion and anisotropic pollen filter, but only on the latest NIVIDIA cards.

The little specks are the thing we’re interested in here. In still frame, they just look like part of the background. But in gameplay they drift around. They get brighter when you hit them with your flashlight beam and they’re obscured by walls.

Like a lot of “field” effects, this one is pretty simple. There are only 400 dust motes in the game. They drift slowly, so the game doesn’t even have to move all 400 every frame. Each one of them moves in a different (but constant) direction. If it drifts off one side of the screen (either because you’re moving, or it is) it simply re-enters from the opposite side. If you could zoom out, you’d see your character has a rectangle of white particles following them around.

Continue reading →

Page 3 of 16« Previous 1 2 3 4 5 … 16 Next »