Yes, these are all XBLIG games coming out this summer. Pretty sick stuff in there, and though I’m not on the list, I have to take this opportunity to give them a shout-out, for many reasons.
First, the amount of effort put forth by Armless Octopus Dave is mindboggling. I’ve seen the XNA forum thread on this event, and it’s gotta be the biggest on the site. Lots of people interested in the event, wanting to join in, with ideas on how to run it, and he’s managed to wrangle it all. I’m seriously impressed. I don’t know how they divide the labor but I have to assume Kris is picking up a good bit of slack as well. I mean, for the IGWU I somehow managed to get credit for helping kick it off without the hassle of doing any real organization (Robert handled that), so I don’t have firsthand knowledge of how much goes into it–but it’s gotta be huge, and we all gotta give props, final cut or no.
Second, I’d still like to see XBLIG grow as a platform. It’s taken a beating this year with the ratings shenanigans (which slaughtered SC2’s profitability–SC1 still outsells it 4:1) so it’d be great to see it get more traction. Maybe there’s a critical point at which Microsoft decides it’s time to add Achievements and an improved top list system, so if we can get closer to that point, I’m all for it.
Why is Escape Goat not on the list? I don’t have a great reason for not entering it, but my somewhat passable reason is that I didn’t have something quite finished enough to nominate. There’s a chance it’ll be done in time for the event, but not a certainty, and with 50+ nominees I figured it’s best to sit this one out. When I get into hardcore game development mode, it’s hard for me to think about anything else. My involvement in the community is sporadic to say the least. (Look at the date stamps on this blog for instance.)
So for now, I’m just looking forward to some of these games. Good luck to everyone and congratulations to the devs who made the first round of cuts.
Tomorrow is another Escape Goat Alpha Playtest Party! That means tonight is a blog post on playtesting, lightweight, indie-style. In other words: you’ve got friends, some of them play lots of games and others don’t, and you want both types to try out your game and give you their valuable feedback.
Throwing a party is a great way to get this free labor from your friends and family without feeling too guilty about it. Just provide them with enough food and drinks to ease your conscience. And it’s not such bad work either, playtesting games.
Now I’m not the master of testing, and a lot of these tips probably come straight from Jesse Schell’s The Art of Game Design. For Soulcaster I, II, and Escape Goat I’ve probably hosted about ten proper playtesting parties, and here’s what I’ve picked up from them.
First question: When to start playtesting? There’s a point during development where you think things have come together enough that you have what could, in some stretch of the imagination, be described as a “game.” Maybe it doesn’t have a beginning/middle/end, maybe the graphics are placeholder and there’s no audio yet, but there’s something there and you can put it in someone’s hands to be judged. This thing that has until now been called a prototype has now somehow become a game. If you’re there, let’s get started.
1. Test it yourself beforehand. If you’re making tons of last minute changes like I do on the day of the party, just be sure you’ve given it one full run-through to make sure you didn’t accidentally delete the switch that opens the door to level 3.
2. Have a cohost. A significant other or close friend will be needed to greet guests, cook food, send out for more beer, talk to the cops, etc. You’ll be way too engrossed in the testing to be a proper host, so don’t even try.
3. Fresh meat first. Anyone who hasn’t seen the game yet gets first dibs, lest they catch a glimpse of someone else’s session and have their first impression become corrupted. If someone else is testing while a newbie arrives, have your cohost distract him or her for a bit. “Have you seen the new patch changes in HON?” for example.
4. Tell your tester to speak their mind while playing. Anything that’s running through their head. Here are some direct quotes from the last playtest:
“Wait, did that do anything?” (after skull activation)
“That’s the same message that I read earlier.” (story tablet at region 1 entrance)
“Did that guy just hit something?” (reaper in level 3 third room)
“I like that he looks really, really scared” (idle edge sprite for goat)
“Why do the blocks have color on them?”
This way, when a player is wandering back and forth in the opening area, you can get an idea of why. Can they not find the exit, or do they just like the walk animation? Personally I hope it’s the latter, because the two-frame goat run visual took me freaking forever.
5. Remain silent. No hints or explanations of how things work. You’re a fly on the wall. (The exception would be a known glitch that hides information and could cost time, for example a tutorial notification that isn’t showing up in this version for some reason, but will be in the final version.)
6. Take notes.
About four testers in one evening generated this many written notes.
7. Have a roundtable discussion afterwards. If you’re making games, odds are you have friends who have strong opinions on games. This is one of my favorite parts of the testing party. I’m surprised to hear what people liked and didn’t like, what they would like to see in the next version.
8. Process your notes and thoughts the next day. I personally love using BlueMind for this, but maybe that’s because I’m a recovering organization software junkie. The point is to get a nice list of bugs to be fixed, major remaining design issues, principles on designing levels going forward, etc.
This is a branch of the mindmap I made based on last week's playtest.
So that’s it, hope this has been somewhat helpful, and if you’ve got additional tips, please post them in the comments!
While none of these tilesets is final, they should give a pretty decent idea of what the game will look like. The jungle level is kind of experimental, and I’m not sure if organic levels really work well with the minimalist/blocky look of the game.
Today was an awesome day for getting stuff done–probably fixed 20 bugs and added several long-needed features.
Today I worked exclusively on the in-game editor for Escape Goat. There is no external editor–no Windows program or special version of the game I use to make levels. Everything I use to create the built-in game will be included with the product!
My goal is to give first-time game designers a toolset for making something. This means making things more user-friendly than I normally would. Usually I just build my editors for stability and speed, but this one’s got to be pretty (enough) and totally straightforward.
The editor as it existed this morning looked like this:
This version of the editor has been working great so far. I have single button presses for every action, so there’s no need to use a menu for anything. This lets me crank out levels and prototype them rapidly. Though it may be really fast for me to use, I built it and have spent plenty of time with it. I can’t expect someone new to jump into this and understand it.
Just looking at this screenshot, we have several immediate problems:
There’s text bleeding off the edge in the properties editor, because it’s using the large, in-game font. Speaking of this font, it’s not going to be very good at conveying button names. Can you tell that’s [RT] at the bottom?
There’s a lot of wasted space at the bottom with the Thing Selector (the big orange box).
There’s no way to know what each window is at a glance.
The windows are out of alignment, and the Thing Selector doesn’t even have a proper border.
Placeholder text for header and footer needs to be replaced with something useful.
To come up with an improved layout, I started with a screenshot and loaded it into GraphicsGale. Its built-in grid and alignment made it easy to move and resize the windows along the 8×8 pixel grid. Not only that, but I could pick a good font size and get exact screen coordinates for all my editor windows.
Did I mention GraphicsGale is the most awesome spriting program ever? Well it’s also good for mocking up screen layouts.
(Several hours later…)
Here’s how the editor looks now:
Besides being easier on the eyes, it has many usability improvements:
Smaller font can show more text without bleeding off the edge.
Windows can have colored strips at the top for header text, which can be a simple label (Region Map) or a dynamic label, like the Thing Selector which shows the category name.
Graphical icons for Xbox controller buttons. This makes such a huge difference.
Map dimensions changed from 11×4 to 9×5. Almost the same size in room count, and it fits better in the editor.
Thing Selector shows 3 rows of 8 things at once, which is less overwhelming, and takes up less space.
The “cheat sheet” on the right is all dynamic depending on where you are in the editor, from the Map Editor to the Room Editor to editing a single gadget within the room. Each strip shows a button, command name, data field, and graphical icon.
The behavior is almost the same, but it’s much cleaner and smoother now. I still have to add some more icons for the cheat sheet, but that should be about it. I’ll post a video soon demonstrating its use, and I hope everyone will find it approachable regardless of their experience designing games!
