Laziness is setting in

Not a question, just a bit of a lament:

I’ve created a bunch of interesting objects, and written the code so they behave the way they’re supposed to when the player does the “right” thing with them (that is, when he uses them in the way which will move the story forward and eventually lead to a “winning” ending). Now the time has come to deal with all the other things the player might try with each object. And since each object can be in a number of different states (each representing a particular permutation of all of the various things that can change about the object throughout the course of a game) the possibilities add up.

No big deal – the number of permutations is not at the totally unmanageable level, and coding the necessary responses is pretty straightforward. The problem is, I’m starting to get lazy. I’m starting to think of reasons to prevent a particular object from getting into a particular state, just so I don’t have to deal with writing responses for every action for that object in that state.

I know it’s a mistake. I know the game will suffer for it. I know what I should do. But I can’t seem to get up the energy to do it.

The other approach would be to move on to something else for now (like working out plotting problems or creating additional interesting objects) and try to convince myself that I’ll come back later to fill in all the missing responses. The problem is, I’m not quite gullible enough to buy that (if any of you believe it, I’ve got a bridge going to Brooklyn that you might be interested in).

Ah, well. :frowning:

Robert Rothman

I know you didn’t ask for advice, but here’s some anyway:

Code all the essential stuff first. Get a working, beginning-to-end draft of your game going. Make sure every activity functions, of course (and make sure your code is well-organized so you can tweak bits of it easily down the road).

Then, do buttloads of testing with as many testers as you can find, have them send in their complete game transcripts, and I can almost guarantee you that when you see them hitting generic responses to things that need clever responses, you will be motivated to code in those clever responses. They’ll also help you prioritize, because you’ll see some of those unacceptably generic responses multiple times, and that’ll be a nice red flag for you.

Really. Laziness on fringe stuff is fine for now, because it won’t survive the testing process. Those testing transcripts will light the appropriate fire under your butt, at exactly the right time for your butt to start burning.

For now, forgive yourself your lack of superhuman energy, and just focus on getting that sucker playable from A to Z.

I think Ghalev’s advice is really critical, because I’ve given up on many IF projects mainly because I was trying to implement all the details of sections of the model world without having a clue of how the whole game would fit together. Sometimes I knew the story I wanted to tell and sometimes I didn’t, but I never developed and implemented a coherently-designed game, and as a result, I always became frustrated and gave up.

I’ve learned that I always need to develop a moderately detailed plan before I implement anything at all. My objective right now is to get a working prototype going. After having implemented most of the locations in the game, as well as a couple puzzles connecting the early-game locations to the midgame region, I discovered that my original plan (which I had somewhat diverged from) was not detailed or accurate enough. I know what puzzles I want, but I’m not clear as to how all the necessary objects are going to work together. I could start coding objects that I think I need, but that would probably be a recipe for another failure, based on my past experiences. Therefore, I decided to call what I have “ALPHA 1” and to step back from implementation until I rewrite my notes more accurately. I may offer my current, very crude and incomplete prototype to a couple people to test.

Robert, it sounds like you’ve developed your game a lot more thoroughly so far than I have mine. You may be well past the “critical” point in development already, whatever that is. I’m sure you will be able to finish your project. I offer my experiences in case they may be relevant in any way. :slight_smile:

No matter what language I have been working in (from Basic through ADA) I have found that doing a skeletal code first then comming back and filling in the details after the skeleten is working is a quite convenient and rappid method. :ugeek:

Should have checked my spelling:

No matter what language I have been working in (from Basic through ADA) I have found that doing a skeletal code first then coming back and filling in the details after the skeleton is working is a quite convenient and rapid method. :wink:

Move on for now. If it makes you feel better, make notes in the code that are easy to find; if you ever hit a point where you want to do one or two things, but don’t have time to get into code, you can always knock a couple responses down.

If you’re using Inform 7, I stole someone else’s method (Matt’s, maybe?) of including << in comments that I want to come back to for sure, ie [<>]. It works really well - it’s a good reminder of the issues I need to work on, especially when outputted in the transcript:

throw someone a bone
<>.

Then you can search the transcripts later for stuff you need to add.

That’s not necessarily lazy. Think of it from the player’s point of view. The player wants to advance the story. Will putting a particular object into a particular state derail the story? If so, does the player really want to derail the story? If the answer is no, than an excuse for not taking that action (or a reason why the action failed) may be exactly what the player wants. Just make it a good one - it could be funny or reasonable or even provide new light on the situation.

But if it’s stopping you from getting it done, don’t do it. I certainly don’t have the same “broken windows” approach to writing as I do to programming. Programming is building a tool according to a specification: Every component has to work a certain way, and that way is clearly defined. So every component has to be right when it’s built. Writing is not like that. All forms of writing start out as a rough draft and then go through a process of editing. IF is no different - you can’t build it to spec because the measure of success is not objective. You have to make something first, and then see how successful it is before you fix it.

In general, my method for combating laziness is to make sure I get something done every day. It could be a line of flavor text, tweaking an extension, a response to an unproductive action, anything. No judgment - judgment kills creativity. There will be time for playtesting and editing later. If you were to ask me what’s stopping you from finishing your project, I would say it’s not laziness, but self-criticism.

Likewise, even though I’m a non-programmer working solely in I7 :slight_smile:

My problem is … and it’s really kind of embarrassing … is that I can’t resist the temptation to refer to my bare-bones functional version as the “wireframe” version of the game. :frowning:

Curiously, I have the exact opposite problem: I focus so much on side track detail and response, that I still don’t have a playable story. The worst part is, a heavy load of the stuff I’ve written is so, so hidden, that I’m starting to think nobody will ever read it.

In my personal opinion, it’s a) fun for the player to discover hidden gimmicks and b) fun for the author to create them. When I used to program for a MUD my friends and I often sat in a bar, drinking beer and coming up with weird stuff very hard to discover. Was a lot of fun coming up with ideas, and even more fun watching players discovering something and yelling “Whoah, THAT WORKS?!?”

Following the way of “rapid prototyping”, like Ghalev described, is good advice to give people in general if they’re flagging in developing a game.

Still, that’s not what I’m actually doing with my game per se. There are different kinds of tasks involved in making these games. There is the writing of prose, the rote writing of code that you know how to write but that has to be done, and working out how to code what you don’t know how to do.

I get bored if I do any one of these tasks for too long stretch, so usually, to break sensations of weariness or laziness, I just switch to a different type of task from the one I’m on whenever I get that feeling. For instance if I’m in a writing mood, I might fill a text file with a bunch of descriptions for different items, rather than code each item in full. Then when I’m in a programming mood, I pull out the text file and start implementing the items I described, one at a time.

So regularly changing which parts of the game you’re working on, rather than doing things sequentially, can be another way to keep yourself stimulated.

Re: using playtesters, there are lots of different approaches as to how and when to give your stuff to play testers. I don’t like to show testers the game until it is very complete, basically because I want the play testers to be concentrating on the game itself more than on the bugs they are hitting. The more technical hitches they strike, the less comparable their experience will be to that of the end user. So I’m sort of ‘preserving’ them, because each of them can only have one first experience with the game.

If I had a pool of testers double the size - and more time, because communicating with your testers is a significant time and energy pull - I would probably have a group who would test the game as I made it, then a second group who would only see it once it was essentially complete (but still with hidden bugs, which they will un-earth :slight_smile:) Anyway, since I test my own games pretty strenuously, I like to keep the testers out until late. It’s just worth thinking about what you want from testers before you bring any in. It has to suit your working style.

I do that too. I also switch around between different areas of the game. I have the ending pretty nearly done now, while the beginning still has a lot of question marks. But I feel like having that ending means that no matter what, the story will have a definite arc and things will work out eventually - I always know what direction I’m headed in. Still, whenever I get stuck on a point of mechanics, or overwhelmed by coding a complicated situation, I skip back to an earlier section and add some conversation topics, or advance the plot a little there.

I feel the same way. If the world revolved around me, I might have testers at every stage to check for bugs and bounce ideas off. On the other hand, maybe I wouldn’t. Getting feedback too early can be distracting.

At this point I want to get everything working to my own satisfaction, and when there’s a complete game to play with no known bugs, I’ll start begging for beta testers. My biggest fear for this approach is that I’ll discover major plot holes, fundamentally broken game mechanics, or just generally negative player responses - I am trying to prepare myself for a major rewrite after I start getting feedback, but I’m a little afraid I won’t be up to it.

I don’t know if you’ve seen it, but there’s a library or extension that lets the player do whatever he or she wants without consequence.
The trouble is the player (me) will stop regarding the story as real life, and treat the IF as if it were AIF.

For instance I could be outside in a crowd with a What do you want to do? prompt.
Here I could say stuff like strip or undress name and nothing would happen to me.