Originally posted on Shamus’ Good Robot Devblog
The date is set. We’re now committed to launch on April 5, or embarrass ourselves forever. Here’s the announcement trailer:
Allow me to anticipate your questions:
Continue reading
Good Robot #43: Un-Unsolved Mysteries
Originally posted on Shamus’ Good Robot Devblog
So now we’re to the part of the project where we have to stop adding Fun New Things and fix the dumb crap and insane bugs we accidentally created earlier. This is my least favorite part of the project. Or any project. The equivalent for an author is once they’re done writing a book and they have to go back and proofread. Bo-ring!
Here are some of the baffling conundrums we’ve unraveled over the last few weeks.
Bug #1: Mysterious Level Exit
Description:
You’re flying around the level, minding your own business murdering robots, when suddenly the Good Robot acts like it just went through a level-exit doorway. The robot flies to the edge of the room, the screen fades out, and you’re suddenly on the next level, despite the fact that you weren’t anywhere near a doorway. You couldn’t even SEE a doorway.
Good Robot #42.75: Pro Strats
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?”
Good Robot #42.5: Good Writebot, or How to Write a Videogame Story in 25 Easy Steps
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 (!).
Good Robot #42: The Framerate Unleashed
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.
 |
Oh Gosh! It’s a Good Robot GIF Gallery!
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?
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!”
Good Robot #40: Overdraw
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?
Good Robot #39: Teaching Players to Play
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.