Yup, it’s on the marketplace, as of this writing sitting at 4/5 stars and 36 reviews. Not really sure yet where it will land in the lists, but it feels great to have it out there, and so far the feedback has been pretty positive. More updates here as the reviews start happening.
Escape Goat Development, New Project to Marketplace: Jan 1, 2011 – Nov 1, 2011
First, Escape Goat has finally PASSED PEER REVIEW!! It will be published to the marketplace within a few days (check back here for updates, or subscribe to my Twitter feed).
I’ve also created a page for the game in the top menu, including the debut of the cover art.
Finally, I’ve posted the official trailer to YouTube:
I’m thrilled to be able to release this title to the marketplace. There will be some new announcements here daily until it comes out, so stay tuned.
There’s this struggle. On one hand, you want to make the best game you can make. On the other hand, you want to actually finish the game. These are the opposing forces that make the creative process so difficult.
There are lots of indie games where I’m playing and thinking, if only they spent another two weeks, they could have bumped it up from a 3.5 to a 3.75. They stopped when they were in arm’s reach of something really polished. There’s some new stuff there, but it wasn’t given enough iteration. Not enough testing. Six months of work to get where they got, and maybe it would have been twice as good with just another two weeks.
Then again, by releasing the game they are able to start working on the next thing.
The problem is that games always seem to offer the most rewards right at the end of the project. You can finally see how things are working, and you’re making awesome strides every day. Just give it another couple weeks, think of how much better it will be!
Knowing how long to spend on the project is one of the most difficult parts of game development for me. I wish I had a formula, or some sort of answer, but I just don’t. There’s something to be said for spending another two weeks, and there’s something to be said for just releasing it even though two more weeks would have improved it.
By popular demand, I’m going to continue this series and dig up some of the relics of the Soulcaster design process. In part 1 I talked about lightweight design and posted shots of a few levels that ended up on the scrap heap. Well for today I’ve found a special treat: the original design document of Soulcaster 1.
I haven’t edited anything besides coloring the text. Stuff in red is stuff that never made it into the final design. Italics are annotations I’m writing today.
Tower Defense Adventure
like tarchon, but more focused on individual rooms with finite enemies and handling “waves” perhaps [Tarchon was an earlier concept featuring one-player party-based dungeon exploration]
take your party into a dungeon room and you start to get attacked. you need to fight your way from room to room within a floor, surviving waves of mobs. when one aggros, all others in a small radius aggro, so they start filing in for the attack. [I never tested this behavior, and it would be cool to have leader and following types of enemies in the future]
there are choke points like in any tower defense so you are facing waves of guys.
basically you set up your defenses by placing party members at key locations. you have ranged units who can fire at enemies, or over walls. aoe based attacks and that sort of thing. there are melee units, some of them can set up barricades. other disables such as stuns are also available. [There were no barricades or stuns. Status effects is something I hope to introduce in SC3, though it will be time consuming to balance.]
when you place a party member, he stays in one spot and executes a simple script. usually it will mean just firing at any enemy in range. it can also mean moving within a small radius to melee attack enemies that come that way. [The random skeleton friends in SC2 were an experiment with melee allies. I could experiment with it a bit more, but for the first game it took away from the unit placement strategy.]
This post is about Soulcaster I, and how it evolved from the first stages. This was the first project I designed and built from scratch, and my philosophy has been to keep the design as minimal as possible. Rather than write a lengthy design document and try to detail all the enemies, their behaviors, the items, etc., I just jotted down some rough ideas and used it as a starting point. To be extra careful, I didn’t even use Word, I just did plain text in Notepad, and didn’t bother with formatting–or even capitalization. This was not intended to be a blueprint I would refer to throughout the project. Continue Reading…
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:
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!
