Submitting my first Game: 3 Quick Lessons Learned from Spring Thing

[pinkunz]

The following was split from this topic at @dee_cooke 's request:

@pinkunz

Thank you for sharing this, @sophia . I have to agree that the process of submitting my first game was a similarly positive experience. While I was ultimately unhappy with my results, twice, I did learn some really important lessons in the process:

1.) MVP - I knew about this beforehand, but I didn’t apply it for some reason. It stands for Minimum Viable Product. The concept being this would be the simplest most scaled back version of what you could charitably consider a finished game. I was aiming for a larger, more enriched experience from the start and built for such. As a result, while I had far more done and far more time into my project, I needed much more time to finish what I had already partially implemented than the time remaining at T-minus 3 days from the deadline. Also, since I started with that larger framework, I couldn’t easily prune the project back without breaking it (Trust me, I tried). So, I took a smaller element that I had added some time after I started (making it easier to disentangle from my tormented mess of a code) and separated it into its own project, reframing a setting and thread-bare plot on the fly. So, I abandoned the bloated carcass of my game 3 days before the deadline and essentially did an unintential speedIF run for a non-Speed comp. The results, while accomplishing that MVP goal (just barely), are not really up to my standards. On the other hand, had I paired my original game down to a MVP before I started, I would have finished that working game ahead of time. I could have then added to that framework with whatever time I had left. If I ran out of time before finishing a section, I could safely ditch it and still have a functioning game. A painful lesson, but one I won’t forget.

2.) Communicate expectations to your Beta-Testers. I had two people I knew from college play through the game and get back to me. One, tragically, treated the thing as some sort of game review (my fault for not articulating what I needed) and gave me generalizations about how he felt about it (sorta helpful), what he would have done with characters/plot himself (not helpful with the time left), and then mentioned encountering numerous spelling/grammatical errors and continuity errors while playing while not specifically naming a single one (Not remotely helpful. When pressed, he could no longer remember where he had seen each error. He hadn’t noted where these errors occurred while playing; he hadn’t been prompted to.). Sending a game file to someone asking them to play it and please give you some feedback isn’t adequate. Entirely my fault. The other individual did a better job, making note of needed changes, but got stuck partway through because I didn’t supply a walkthrough. Thoroughly communicate your needs to your betatesters and supply them with the tools and resources (map, walkthrough, etc) to do the job right. Also, leave enough time to implement any changes the beta-testers suggested. There were some great ideas for improvement that I sadly could not capitalize on.

3.) Identify any new functions or implementations early in your project. Create small test modules to wrap your head around working code for each new situation before committing to your MVP. You may realize that implementing that *.GIF file or tying the current system time into your project may be much more involved than originally expected. You don’t want this realization to occur very late in the project.

Thanks again,

-Pinkunz

@dee_cooke

@pinkunz - I have quite a long response to your post in my head but I don’t want to drag Sophia’s thread off topic - perhaps it might be worth starting a new thread?

[dee_cooke]

Thanks for the new thread!

I think releasing these things is such a huge learning process. I relate so much to that ‘argh, three days from the deadline and nowhere near finished, better make a whole new (smaller) game!’ feeling, because I have been there three times before! What comes from it can be brilliant or terrible or both

Beta testing, oh goodness, also a learning curve. For my first nearly-two-years of making games, my husband was my only playtester. I still find it incredibly useful to have a playtester who doesn’t play a lot of IF, but I think it’s more beneficial to have playtesters from within the community as well, because they will know from their own experience where the bugs are likely to be found, and will have more of a sense of what the author will need from the testing - although yes, you’re right, it’s definitely good to tell testers upfront what you’d like them to focus on!

Even with that kind of focus, there are always going to be unexpected things that come up in testing, I think, and it’s similar to the actual ‘making the game’ part in that you always end up needing longer for it than you think you’re going to need.

Things that take far longer than expected… I think, again, estimating timescales for parts of a project improves with experience, but it’s certainly not something I’ve fully cracked yet! I think it’s also useful to classify examples like your GIF file as ‘nice to have’ if you’re short on time, then it’s not as disappointing/frustrating if you don’t get round to them.

Going back to your first point and what you said about not being totally happy with the standard of your final game - I think this relates to an interesting and common issue, because I know you’ve said elsewhere how important it is to you to start getting your games out this year through all the comps and jams that are happening (which is something I also relate to very much). I think when we’re up against a deadline and nowhere near having the game we envisaged on our screen, it’s a real dilemma between two choices: do we submit something, anything, so that we can feel that satisfaction of having submitted, or do we wait for another competition and make the game what it should be? I have always chosen the former myself; the one exception was this current Spring Thing, and I still feel incredibly wistful about missing out (even though I know in this case it was the right decision). It’s one of those things that can be so either-or, because it’s possible to get so bogged down in perfectionism that you’d never get anything released without these external deadlines. I’m keen to see how your last-minute Spring Thing entry relates to your original project - did you say you’re now planning to submit the original one to ParserComp? It’ll be interesting to play both.

Good luck with the onwards and upwards!

[AmandaB]

@dee_cooke

it’s possible to get so bogged down in perfectionism that you’d never get anything released without these external deadlines

After just submitting my second game, I’ve come to feel the same way about “finishing” a game as I do about renovating a house. You’re done renovating when you run out of patience and money. You’re done with your game when you run out of patience and time. With both my games, I got to the point where I just could not look at it ever again after all that time obsessing and tweaking.

@dee_cooke

I still find it incredibly useful to have a playtester who doesn’t play a lot of IF, but I think it’s more beneficial to have playtesters from within the community as well, because they will know from their own experience where the bugs are likely to be found, and will have more of a sense of what the author will need from the testing

I could never have finished either game without the testers here. And I’ve come to understand how important it is to have testers who will be really hard on your game and try to break it, which requires people experienced enough to know where the weak spots are likely to be.

@pinkunz

Minimum Viable Product. The concept being this would be the simplest most scaled back version of what you could charitably consider a finished game.

This is totally foreign to me. My nature is to complicate things, not simplify them. MVP seems like an excellent lesson for a beginner to learn, but I wonder if I’m capable of learning it.

[pinkunz]

@dee_cooke

Thanks for the new thread!

Thanks for responding to it!

@dee_cooke

I think releasing these things is such a huge learning process. I relate so much to that ‘argh, three days from the deadline and nowhere near finished, better make a whole new (smaller) game!’ feeling, because I have been there three times before! What comes from it can be brilliant or terrible or both

That makes me feel immeasurably better, thank you.

@dee_cooke

Beta testing, oh goodness, also a learning curve. For my first nearly-two-years of making games, my husband was my only playtester.

It’s very cool that your spouse is into what you do. I wish I could interest my wife as much as your husband.

@dee_cooke

I still find it incredibly useful to have a playtester who doesn’t play a lot of IF, but I think it’s more beneficial to have playtesters from within the community as well, because they will know from their own experience where the bugs are likely to be found, and will have more of a sense of what the author will need from the testing - although yes, you’re right, it’s definitely good to tell testers upfront what you’d like them to focus on!

I discovered how to turn transcript mode on for the Beta-testers…

Today. I discovered that today.

t o d a y

@dee_cooke

Things that take far longer than expected… I think, again, estimating timescales for parts of a project improves with experience, but it’s certainly not something I’ve fully cracked yet!

Leaning towards heavily overestimating going forwards.

@dee_cooke

I think it’s also useful to classify examples like your GIF file as ‘nice to have’ if you’re short on time, then it’s not as disappointing/frustrating if you don’t get round to them.

Strongly agree. Mental note taken.

@dee_cooke

I have always chosen the former myself

The most important promises to keep are those made to yourself. It’s not a commitment if you don’t keep it, right?

@dee_cooke

…the one exception was this current Spring Thing, and I still feel incredibly wistful about missing out (even though I know in this case it was the right decision). It’s one of those things that can be so either-or, because it’s possible to get so bogged down in perfectionism that you’d never get anything released without these external deadlines.

I am hoping (perhaps naively) to have my cake and eat it too. As long as I can actually drag my original project over the finish line for ParserComp at a standard I can still sleep with, I’ll consider all commitments, both internal and external, met…

Until I immediately overextend myself again, lol.

@dee_cooke

I’m keen to see how your last-minute Spring Thing entry relates to your original project - did you say you’re now planning to submit the original one to ParserComp? It’ll be interesting to play both.

I did say that, yes. Watch for a post-comp version of Adrift; beyond bug fixes and general improvements, I hope to better tie it in with the Parsercomp release with some well-placed easter eggs.

@dee_cooke

Good luck with the onwards and upwards!

Thank you very much! You’re not doing too poorly in that regard yourself!

[AmandaB]

@pinkunz

It’s very cool that your spouse is into what you do. I wish I could interest my wife as much as your husband.

My husband will not, will not, WILL NOT play a parser game. Ever. At all. He will occasionally play a CYOA game where there’s no typing involved, but he’ll never play one of my games. He’ll read through a transcript, but that’s it. Sigh.

[pinkunz]

@AmandaB

I’ve come to feel the same way about “finishing” a game as I do about renovating a house. You’re done renovating when you run out of patience and money. You’re done with your game when you run out of patience and time.

Agreed to a point. If you don’t have a functional game at that point, you don’t have the luxury of calling it quits. To use your same analogy, let’s say you’re renovating your house; new kitchen, new bathrooms, new open spaces, new roof, new addition, new HVAC, and an upgrade from that gravel driveway. You start by gutting your kitchen and both bathrooms and then knocking down numerous walls for “open concept.” You start the tile work in one bathroom, but it is tedious amd painful. So, rather than finishing that first (Because everything has to get done anyway, right?), you move on to pouring a foundation and framing out your addition. You get your best buddy Paul to start removing the old roof while you are still framing the addition. You need the dumpster taken to make space for the driveway people, but you want your money’s worth, so you interrupt Paul mid-roof so he can help you quickly rip out the (functioning) old furnace and radiators and toss them into the dumpster before it is rolled away. Your addition is framed, but not sided or roofed at this point. All work then ceases for a time as everyone has to move their vehicles to allow for a pouring of a new concrete driveway, but there’s no on-street parking and by the time new parking arrangements are made and everyone car pools back down to the house, it’s late, and you are forced to simply call it. At this point, you have arguably done a lot, and you may be dirty, tired, and hungry while running low on time, money, and patience, but you cannot stop.

The house isn’t a minimum viable home at this point. It’s not even a weather-proofed shack.

Oh no! Spring break is tomorrow and your son, Brian, is driving home from college to spend it at home. Well, poop. I guess I’m looking for an Airbnb…

[AmandaB]

@pinkunz

The house isn’t a minimum viable home at this point. It’s not even a weather-proofed shack.

Of course I take your point. Roofs must go on, no matter the cost. But I have never known anyone who renovated a house who didn’t leave some things unfinished, and I wonder if anyone EVER feels as if they have truly “finished” a game. I think it’s probable that all games have some holes without light fixtures, or places under the fridge that never got tiled. I’m into the wine now, but I think my point is that nothing is really ever “finished.”

[HanonO (Hanon Ondricek)]

@dee_cooke

I think releasing these things is such a huge learning process.

This. So much. One thing that new authors can’t have any concept of is beginning to end. Starting a project is easy. Finishing one is hard. Releasing something requires a lot of (often unexpected) late-game crunch work and if someone has never finished a game, they naturally won’t have any concept of the entire “through line” of release.

That’s why I always encourage people to write several smaller things they have better chance of finishing and release them before they move on to the huge epic game they hope to make, because they will learn so much about their own abilities and have a concept of the end-to-end commitment necessary that will assist them in realistically scoping and planning a larger project.

@AmandaB

@pinkunz

Minimum Viable Product. The concept being this would be the simplest most scaled back version of what you could charitably consider a finished game.

This is totally foreign to me. My nature is to complicate things, not simplify them. MVP seems like an excellent lesson for a beginner to learn, but I wonder if I’m capable of learning it.

Scope-creep is the devil! This is why it’s best to plan, outline, prototype your entire project and know every system and element you have to include instead of “this is a great idea! I’ll figure out the end as I go!” I’ve done that so many times and shot myself in the foot because once you start, you fall in to the death-spiral of polishing the beginning without any idea of the end - so you’ve got a beautiful foundation and no material (beyond conceptual) to build the house.

The modular idea is also great. I fell into that with Baker of Shireton because I had unknowable IRL issues that might cut into my production time. If you get the base “MVP” part of the cake made and frosted, then you can worry about decorations and another layer, but you’ve got a deliverable whether that works out or not.

[AmandaB]

NO. MUST HAVE MORE FROSTING ROSES. No cake underneath? No problem. Just more frosting roses.

This is what my brain tells me. Although I actually am writing a game where I started with the basics: beginning, mechanic, end; and now I’m frosting it. But only because it all came to me in a dream. No kidding.

[jnelson (Jim Nelson)]

@AmandaB

my point is that nothing is really ever “finished.”

Steve Jobs’ “real artists ship” is one of those quotes that has stayed with me. Gatekeeping aside (who gets to decide what a “real” artist is?), I do think it’s right in placing a lot of weight on the shipping stage of producing art.

I’ve learned there’s three steps almost no book or guide on writing discusses:

1. The take-a-break stage. When I think something is finished, I walk away from it for a week or two (or more) before doing a final edit pass. Now I’m finished (and I’ll know if I’m not).
2. The shipping stage. As @HanonO said, releasing is more difficult than it looks. I’ve learned to schedule time for releasing, it doesn’t just happen.
3. The walking-away stage. When I’m rested and ready, I pick up a new creative endeavor and get it going.

Congrats to everyone who got their entry in!

[HanonO (Hanon Ondricek)]

@AmandaB

This is what my brain tells me. Although I actually am writing a game where I started with the basics: beginning, mechanic, end; and now I’m frosting it. But only because it all came to me in a dream. No kidding.

Well, sometimes it is like that. Many a screenplay or short story or small game has been written in a white-heat weekend just based on a flash of inspiration and creativity! That’s why there are speed-IF comps - to grease that type of creative machinery.

But relying on the muse to grab you by the scruff of the neck like that every time is a roulette wheel. Especially with a larger work. It’s okay to do the “how long has it exactly been since I ate?” type of creative frenzy occasionally for a short time, but not on a regular basis!

[pinkunz]

@HanonO

It’s okay to do the “how long has it exactly been since I ate?” type of creative frenzy occasionally for a short time, but not on a regular basis!

I actually stayed up overnight Wednesday night to cram more work into that game.

(Note: Don’t do what I did. Bad, no good, terrible idea.)

[HanonO (Hanon Ondricek)]

One strategy to secure beta testers: If you know you are entering a comp, find out early who is also entering and team up with one or a few of them to trade feedback. This has the added advantage that you’re not removing a potential voter for your game by having a non-entrant test.

It can be hard to do this a week before the deadline though!

It was really great that threads started to help with blurbs and cover art, there was some awesome feedback from everyone!

[slugzuki (kit riemer)]

(caveat: I don’t know if this is useful or actionable info, lol)
With both my games, I started them without more than a rudimentary plan and designed/wrote the bulk of them as I went (which probably explains some of their shortcomings). I refined the structures by playing them over and over and seeing what felt good and what wasn’t working, what moments dragged, etc. I try not to write endings until I’ve got the bulk of the game written/coded but also fleshed out and pretty polished, because 1: there are often fun little details/callbacks I can include from the sections that are already done & 2: finishing a first draft in its entirety seems to cause me to gradually lose patience & interest in working on the game, so I know once I have a completed product that can be tested, I’ll only want to work on the game for another few weeks at most before I’m kind of sick of it.

I set no real deadlines for myself with Computerfriend, just kind of assumed it would be ready with a comfortable margin of time prior to Spring Thing (which it was, luckily). However, one thing that really helped was when a friend offered to test an early version and I realized the game would be unsatisfying to play without an ending… resulting in me very quickly dashing together four endings, which I later refined & fleshed out into the six that are in the final game. If I’d missed this deadline it would’ve been totally fine, but I still found it a useful kick in the pants, and the situation has made me question my rather structureless & unscheduled approach to gamemaking.

Jim mentioned the importance of the take-a-break stage, and I cannot agree more. When I come back to a game (or a short story, or a collection of photographs, or whatever I’m working on) after some time away, I feel like I can be a lot more objective. There were a few moments in Computerfriend that felt off to me when I wrote them, but coming upon them after a break of a couple weeks I could immediately identify why I disliked them: they were cloying, or unnecessary, or didn’t fit the mood of the scene. That’s the most important takeaway I’ve gotten from all the creative projects I’ve worked on: don’t consider it done until you’ve taken a break and returned to examine it with fresh eyes!

[Alianora_La_Canta]

I found it helpful to allow a month for testing and refinement of the MVP. That allowed me to get three-and-a-half cycles of testing done with my testers (the “half” was because I got the music in shortly before the deadline and sat with one tester to make sure the music didn’t crash the game).

Also, a method I find helpful to do a minimally-viable-product is:

1. Have an idea.
2. List everything you need to make the idea work in a notes file.
3. Create a blank second notes file (mine is labelled “addition pool”).
4. One (or a few) days after you do this, go through your notes file. Ask yourself if the game will still work if the item is removed. If the answer is “yes”, cut-and-paste them to the addition pool.
5. Implement the notes list. If you get any extra ideas during this time, and they’re not in service of fixing a technical error, put them in the addition pool, in the minimum level of detail needed for them to still make sense afterwards.
6. Once this is done, test it personally, then save it far away from your “working” development copy of the game. This is your MVP, and will be a useful reference later.
7. Do a round of beta testing.
8. If you have time (I advise leaving a 2-day margin for submission to Spring Thing for first-timers, especially if you have several versions to upload and/or your game is at the larger end of the 100 MB limit and your connection is slow), look at the addition pool and implement whatever takes your fancy, one item at a time. (At this point, you can implement multiple things between playtests if your time-frame allows it).

Beta test advice will depend on your situation. I like to provide a week per round of testing (my post-comp version is up to test round 9, though the last 2 were just to add/bugfix more languages), but allow this to vary according to the schedules of your proposed testers. I think it’s instructive to do a supervised play-test with at least one person - it’s possible to learn a lot about factors that don’t necessarily get mentioned (or are understated) via online communication.

What I ask people to do depends on how much they know about this type of fiction - someone who last played a computer game in the 1980s and has never played interactive fiction before is particularly good at spotting problems like bad tutorials or unfocused goals, while a veteran of interactive fiction is likely to be better at spotting things like unintentionally unwinnable situations or pacing problems. Give the “spot the spelling” assignment to people whose spelling you respect, and the “is this explanation misleading or just plain offensive?” to someone who knows what it is you’re trying to explain (I didn’t do a good enough job on the latter, but thankfully one of the Spring Thing players on this forum was very nice about explaining the problem, which meant I could revise it). It’s OK to give different people different things to particularly look for, though I would always make sure people know to tell you if they find something that stops the game in its tracks, or paragraphs that read like someone threw a pile of words on the floor.

[EJoyce (Emery Joyce)]

I agree with this – I mean, maybe there are people out there who can look at a game and really feel that it’s done, they’ve done everything they wanted to do with it and are completely satisfied with the results, but IME there’s always more that you could do, stuff that you could improve or rework or add or flesh out. But eventually you just have to call it done, both because you’d never release anything otherwise and because I think at a certain point further tweaking has diminishing returns, or can even result in a worse game.

And while I’m not as prone to “I’m so sick of working on this, I just want to get it out there,” I do think the longer I work on a game the less I like it, because when you’ve been staring at it for too long you can see all the little things that don’t quite make sense, and you start second-guessing yourself about whether any of the jokes are actually funny and/or whether any of the bits that are supposed to be emotional are actually moving at all, because you’ve read over them so many times that they don’t do anything for you.

At the same time, I have released a game where I felt like I’d significantly compromised on what I had wanted it to be because I ran up against the time limit, and that was an unpleasant experience and I’d like to try not to do it again. But mostly I think deadlines are useful as both a motivator and a way to make myself stop poking at things. For some reason I had particular trouble with this with my Spring Thing entry this year – even now I’m like “but what if I poked at it some more, though?”

[HanonO (Hanon Ondricek)]

@EJoyce

I mean, maybe there are people out there who can look at a game and really feel that it’s done , they’ve done everything they wanted to do with it and are completely satisfied with the results, but IME there’s always more that you could do, stuff that you could improve or rework or add or flesh out.

“All art is knowing when to stop.”

— Toni Morrison

[pbparjeter]

The modular idea is also great. I fell into that with Baker of Shireton because I had unknowable IRL issues that might cut into my production time. If you get the base “MVP” part of the cake made and frosted, then you can worry about decorations and another layer, but you’ve got a deliverable whether that works out or not.

I took the modular approach this with my entry too, creating a sort of sandbox game where players do not have to do every puzzle.

I am hoping this makes it bug-resistant…ie. players can just go and do something else if one puzzle doesn’t work properly. As long as the start of the game and the end of the game work properly, that’s enough for a playthrough.

We will see how it goes. Club Floyd seemed to like it.