I’m just looking to hear your thoughts on the following:
are first versions of first games always crap?
because I just got some first impressions of the first beta of the first game i made and i facepalmed so much at these little things that i think should have been so evident but i just didn’t think of them at the time
… but then again that’s what beta testers are for, right?
Sometimes more, sometimes less. The more experience you have, both as an author and as a tester, the more you’ll know what sort of bugs to look out for beforehand, and the more you’ll get a feel for how players will approach your game. Building your own testing structures (e.g. automated test scripts) before sending the game to human testers also helps. But you’re never going to be able to think of everything. Any software much more complex than “Hello World” is going to have at least one facepalm-worthy bug in its first beta.
And yeah, that’s what beta-testing is for. There’s no shame in it.
Speaking strictly from my own projects: yep, the 1st version is pretty much a disaster zone with crap sprinkles on top. Just accept that this is part of the process and you’re already way ahead of many new authors by recognizing that it needs work. Heck, even Steven King still says that his first drafts are so embarrassing he’ll only let his editor see them. One of my first games was a murder mystery that at the time I thought was kind of cool but looking back now there are some pretty cringe-worthy elements and writing.
My suggestion now would be to step back from your project for a week or so, don’t immediately start changing things. Spend your time doing something that inspires you to create like reading game design books (or if you ever wanted to call playing videogames “research” now’s the golden opportunity) but don’t do any work on your game at all for a few days. I’ve always found that when I get back to a project after a break, a whole bunch of ideas and things have been brewing in the background of my mind that I hadn’t even really be aware of and this is when I’m the most creative.
Anyhow, good luck! You’ve still got plenty of time before the comp
The first draft of everything is garbage. Design, and writing, are iterative processes. You try to approach what you want to have at the end step by step. In film school, I was taught not to expect a screenplay to be decent until the fifth or sixth draft. And that’s for a short.
The best advice I have is to have discipline: Don’t write (or code) when you’re supposed to be editing, and for chrissake don’t edit when you’re supposed to be coding (or writing). I know people who basically never finish anything because halfway through writing a draft they fall down the rabbit hole of editing (and self-doubt) and never come out. Work in passes, finish one section then move on to the next. Try to produce distinct drafts and set specific goals for them, specific problems you’re aiming to solve. Ideally, iteration works like sanding: You’re using finer and finer grits on each pass. So the first few drafts involve gutting things and bolting new things on, making big sweeping changes, and each subsequent draft is concerned with smaller and finer changes.
That certainly depends on what the first version is. The first complete beta-version of my first game, The Baron, wasn’t too different from the final version; but I had already spent a lot of time myself playing through, editing and perfecting the earlier scenes. If, on the other hand, you write an entire game first and only start the polishing process after that – which is not necessarily a worse option – then the first complete version of your game will probably be pretty bad.
Testing software is not generally something even most programmers are very good at, much less writers. Writers will tend to rewrite many times. Programmers will often test, but will also often write bad tests that don’t cover as much as they should.
It’s what I call a “high skill”. Something that requires discipline and effort.
When creating an IF game, you should go into it with the understanding that half your time will be on testing.
Here’s the thing about beta testing. Your beta testers know the game isn’t ready yet. That’s why they’re beta testing.
The responses you get may be hard to read. You threw your heart and soul into this, and things are broken and things are buggy and whatever you tried to do didn’t work. I have all kinds of emotions when I get playtesting feedback! (I wrote about that a bit here.)
But it’s better to hear it now than in competition reviews. This is your chance to address all their complaints. (And run it past them again. And address the new complaints. And rinse, and repeat.)
When you’re done, there will probably still be complaints - after all, IF players are picky and have a wide variety of opinions about how games should be designed. But the complaints will be about something other than how your game didn’t work. And no one but your beta testers will ever have to know how broken it was.
I stand corrected! It seems that Evans has switched to choice-based, then. Which makes sense, as it allows him to expand on his ideas without having to worry about the tons of work that go into even the simplest of polished parser-based games.
Though even in that review Short mentions a continuity error. That sort of thing can happen to anyone, but when it happens to Evans it’s hard to divorce it from context.
Mind, I really don’t want to be too harsh on the guy. He was seriously creative. And ambitious. Everyone who played his games went “This could have been a masterpiece, if only it had been properly tested!”.
Reviews of his games are lessons to any game developer who thinks they can do without beta-testing.
Seriously, I did find it funny that Emily Short didn’t mention Evan’s background in her review - because there are certain names (Andy Phillips, Rybread Celsius, Paul Allen Panks, John Evans)* that are SERIOUSLY known for their entries in IFComps. If it’s not the same person that’d explain it.
*I’m not lumping these together because they make similar games. Good lord no. But they are all notorious; names that pop up again and again, having games in a number of Comps, and all of these authors have a particular, immediately recognisable style. Andy Phillips in particular I really, really, really like - the later stuff rather than the earlier; I keep hoping he’ll make another game.
EDIT - Mind, the review of Gilded that’s in IFDB is curiously in sync with what I’d come to expect from the creator of Castle Amnos and Order.
EDIT 2 - In 2004 we have ORDER, by John Evans, where the gimmick is the ability to create objects.
In 2005 we have GILDED, by John Evans, where the gimmick is shapeshifting and creating things.
No, I’m not insinuating anything, but it IS quite interesting, isn’t it?
I’ve no idea, and am quite curious about it, but it seems to be a fait accompli.
If it IS the same John Evans, then I’m sorry to say he simply did not learn the lesson. From all accounts, the ideas behind Gilded are awesome (and the note in Gilded about “creating only items relevant to the fantasy setting” is reminiscent of some reviews from Order where people complained that, in the game’s setting, you could create some anachronistic items that really jarred), but it’s all but unplayable.
Back to the topic and the learning process - taking other people’s examples is also a way to learn. You do not want reviews like this. The way not to get them is to get your game tested, and listen to your beta-testers. It really is as simple as that.
I remember thinking my first game was absolutely amazing when I wrote it, but when I played it later on I groaned at how bad certain parts of it were. A maze? Random deaths? Ground-breaking bugs? There was even one part you couldn’t reach because I’d missed an exit out of a room.