Since I am writing my first game, I thought it might be interesting to hear about people’s experiences either with writing a first game in the past, or right now. Potential topics include language, prior experience with application development (or not), challenges (technical, gameplay, or both). Also, how is it going or how did it go?
Alternately: just say whatever you like about your first game.
I am writing an Inform 7 game. The first region is small (two rooms), but I had to make a bunch of verbs, and create 3–no, it is 4–tables. Almost all of my time has been spent on structural stuff. I am only just now through with the technical business and now will clean up the feedback. I have never been a programmer, but in my old IT life I did occasionally write scripts and queries.
I got discouraged a couple of times but am glad to get back to writing prose–an activity that I am much more comfortable (and experienced!) with.
I had a practice little game before my first real game. I used Inform 7 for both.
My first real game, Ether, was mostly modelled on stuff from Emily Short’s game Glass, since that was the first real code I had found online. So that’s how I learned how to do stuff like ‘release with’ and other metadata.
Before I wrote my own game, I had some experience as a junior C++ developer in my teams, then some java for math modelling in grad school.
I couldn’t remember what was challenging, so I went and looked at the code (available here). It looks really different from my current code, but not in the way I expected! It’s actually quite a bit more complex than what I currently do; kind of made me bummed that I’m getting dumber lol.
But as I looked at it more, I realized that most of the attention I put into the game was focused on trying out every Inform 7 technique (like quotes, scenes, internal time, tables, extending parser input size, etc.). I didn’t really think of the game as a whole, and most people’s criticism focused on the actual storyline. So I guess my challenge was that I got too caught up in the technical aspects and neglected story.
this does sound like a first game pitfall. I know that, as a beginner in other fields, I sometimes pushed myself to do it all. I’m not trying to do everything in this game, but I didn’t really limit myself when I thought about the story or how I wanted the gameplay loop to work. My imagination has written some pretty big checks, I think.
In my first year of doctoral studies, I did this wild quantitative survey of literary criticism of a specific author over time. It was ambitious and highly unusual–I think people were impressed. Someone suggested I might have plagiarized it, which I always take as a complement.
In that case, I was focused on pushing myself technically rather than looking at, as you say, the story. Other than the novelty, I don’t think it’s something a scholar would cite. So I find your post relatable, even if my own lack of programming confidence will likely keep me out of trouble on that front.
Writing my first game last year was a comedy of errors, which didn’t seem so funny at the time (and probably not to my testers, either). Since I’d never coded anything before, it was kind of a disaster which miraculously turned out OK since I placed well in IFComp. I’m still not sure how that happened. I’m willing to bet that jaws dropped over that given how public my coding ignorance was.
The challenges were largely technical of course, but I think the hardest thing aside from that was trying to tread the fine line in cluing puzzles. Giving the player too much help sucks; too little help sucks even more. I had the same problem in Fairest, and I wonder if that ever gets easier.
I discovered something interesting (to me) about my process: I can write out a storyline before doing any coding, but a whole lot of that ends up in the trash, and a lot of the best ideas come to me while I’m coding. So a lot of what I write is totally on the fly despite my best efforts to plan.
@kamineko- Are you submitting this game to Parser Comp? Or is it going to take much longer?
It will definitely take longer. I’ve finally gotten a lot of what I guess I’ll call infrastructure built, but I’m sure things will have to change as I go.
It is now envisioned as a big game. Not so much in terms of the main throughline, but there will be a lot of environmental implementation. There’s a mechanic that I think players will want to try on everything, so it will take time to make those experiments rewarding. I’m not even sure if it will be done in time for IFComp, though I would like that.
My first publicly available twine game was Great-grandmother and the War, which I wrote in 2015-2017. I have… mixed feelings about it I guess. It fell into a lot of the common criticisms of twine: it was almost totally linear and could have been a short story. Basically it didn’t use interactivity in any real way; the choices and minor branches were there for the sake of having choices. It was all just, do you want to do the interesting thing or the boring thing. Do you want to see this content branch or not. On the other hand, it fits right in with my other games thematically, and the two main characters have basically the same archetypes as Karen Zhao and Emily Chen. I wrote a postmortem of the game last year.
This was also my last twine game because I found that I preferred using a text editor to using the twine UI (I think this was before twee was standardized; there were several incompatible implementations and it was kind of a mess).
My next released game was A Christmas Party, which was a rather short game written in Raconteur, which is another language I never used again. The whole game was reused as one scene in Pageant. In retrospect this was a preview for NYE2019. I stopped using Raconteur because I had discovered dendry, which I thought was a cleaner language with better features for storylets and quality-based narratives, which I became interested in after binging Emily Short’s blog and reading everything she wrote on narrative design.
I feel like I moved in the opposite direction as some people here, as my games have gotten more technically complicated and game-y/mechanics-heavy since my first few tries. NYE2019 and APBW both needed heavy modifications to their base systems (choicescript and dendry), and both have some systematic mechanics and a fairly defined structure.
In your postmortem for Great-Grandmother and the War, you wrote that you “thought a lot more upfront about how the interaction system was going to go, and how to structure the story around the player interactions.” In writing studies, we’d call this sort of thing “intentionality” (you likely already know this!), and I think it’s paid off in your later stuff. The social media interface for APBW is novel and serves as a way to express its themes, and I’ve been pretty open about my appreciation of NYE2019’s “status” screen.
Choice games do often get criticized for linearity, but the authors of parser games (or even controller-in-hand mainstream video games) might also ask themselves: what is interactivity adding to this experience?
Thanks for the postmortem! I haven’t played Pageant yet, but I intend to.
My first proper game that wasn’t just me following a tutorial was Vampire Ltd. The idea of a vampire puzzle game had been knocking around my head for a while, and I’d had big plans for it - lots of locations and cool puzzle ideas. But I know myself well enough to know that if I had tried to do all this, I would have got bogged down and never finished it. Also, because I was aiming for IFComp, I wanted to be sure the game would be beatable in under 2 hours. So I scoped way down to a handful of locations and puzzles and NPCs to make the project manageable.
In doing so, I fell into an unexpected pitfall of over-scoping. What I thought was a 90-minute game turned out to be beatable in a casual 30 minutes, the puzzles were a little too easy, and in general I think a few people wanted a lot more game. But I got more positive feedback than negative, and the game placed pretty well in a crowded IFComp ballot. So I think going small was the right decision for me in the end.
I guess the problem I have with scoping is that it’s very delicate, and a little change can be way more dramatic than I think. If I add an object to my game - say, a sausage roll - I have to think of the context of the object (does the player just find it lying in the street? Do I need a sausage roll vendor NPC and a buy action? Do I need a bakery location?), the verbs the player may expect to use on it (do I let the player eat the sausage roll, meaning I need to let the player get another one if they eat that one? Throw it? Break it apart? Bribe an NPC with it?), and the potential interactions with other objects and NPCs that the player may want to explore (shouldn’t there be a special response to trying to give the sausage roll to the vegetarian NPC? Shouldn’t the sausage roll vendor notice if the player consumes 10 rolls, one at a time, right there in the bakery?). Likewise, removing an object may leave lots of ripples in a project that take forever to clean up (I want to remove the roll; now I need to clean up all the lines of code like “Instead of giving the roll to the vegetarian…” otherwise the Inform project will hang; now the bakery has no purpose so I ought to remove it too, which means removing the bakery from lists of rooms and changing the dialogue where your roommate asks you to go to the bakery…). It’s a lesson I’m relearning in my current project. Combinatorial explosion is a real killer if you’re not expecting it.
I did a postmortem on my first game, which goes into a lot of detail on the process – similarly, I’m a non-programmer with a tiny bit of long-ago coding-type experience who made an Inform 7 game.
Some high points that are potentially interesting to share:
My game started with a three-act structure, and ending with a three-and-two-halves-act structure. I had an overall sense of where the story would go, but more or less moved through each act linearly in a design-implement-polish cycle. In the implementation phase, I also moved pretty freely between writing and coding. This wound up being pretty motivating, since whenever I was feeling bored with doing structural programming, it was pretty easy to switch gears and write some jokes or punch up the prose, and I was able to alternate in-the-weeds debugging with big picture tasks like thinking up puzzles. For my second game, I took the approach recommended by Emily Short and others of implementing a minimal version of the structure and then doing more writing, polish, etc., which I found much more of a slog, FWIW.
I also sorta had each act focus on a different part of Inform in order to teach myself the relevant skills: Act I was meat-and-potatoes stuff; Act II was more timing and condition-based puzzles; Act III was scenes and alternate solutions; then the finale was kinds (and I guess the help menu taught me tables, sorta). This wasn’t systematic – I didn’t have a part that taught me relations, and in fact I still don’t really understand or use them, for example – so I don’t think it went too overboard in a way that a player would notice, except that the first act has a dumb rope puzzle that’s really just there since I wanted to tech myself how ropes work.
I was able to get a beta version done in mid-August, which gave me a good amount of time to find testers and implement their feedback (hi @rabbit!) Everyone always says this is the most important thing for authors, especially parser authors, especially especially first-time parser authors to do; they are right.
I found Inform not that hard to get a handle on? In the first act I definitely did more copy-and-pasting of code I didn’t understand and implementing hacky workarounds without knowing what I was doing, but for most of the rest of the game I did a better job of digging into the documentation, trying to actually grok the principles, and coming to the forum with questions, which was a much better way of doing things (then I decided to center the finale puzzle on fiddling with multiple interchangeable copies of a kind, which is tricky to do and led to more hackery). Of course, this meant that some dumb decisions I’d made in the beginning forced me into even more, even dumber workarounds later on, since I was too lazy to do a total rewrite of problem children like the dialogue system. I’d have probably been better off having my first game be shorter, so I could have left these growing pains behind more quickly and embark on a more robust second game as a more experienced author – but this was the game I was excited to write so I can’t regret this too much!
Releasing my first game in IFComp was a little intimidating but lots of fun! There’s great camaraderie among the authors, a fun authors-only forum, and there’s just a lot of energy and excitement. Spring Thing (and now ParserComp) are really cool too, don’t get me wrong, but I think they’re lower-key. I can see different folks seeing the latter as a selling point and better way to dip their toes into the water, though (my game also had a somewhat-undeservedly very positive reception, which might be giving my rose-colored glasses about how anxious I was at the outset!)
One last point about this:
Since my first game was puzzle focused, I found I could design it the way I’d prep for a tabletop roleplaying game session – like, I’d jot down notes on locations, bullet points with snatches of dialogue or jokes or evocative phrases to work in, and a rough idea of the challenges and potential solutions. Then implementation was kind of like running the game, where I’d work those details in, improvise alternate solutions or realize what I’d planned on didn’t work, etc. I’m glad I didn’t “overprep” since I think it would have led to wasted effort, since as Amanda says your perspective often shifts once you’re in the weeds and seeing what’s resonating and feeling effective.
Anyway, congrats on your game, I’m looking forward to checking it out once it’s done!
Now that I have the verbs ironed out, this is the main thing I’m thinking about. I’m making it a little easier on myself by having several small, discrete regions instead of one big map, but I want to reward player experimentation. The possibilities for each object x each verb must be considered, even if I can’t give elaborate responses for each possibility.
Long, long ago, I ran OG AD&D and Gamma World games. I think those experiences are pretty helpful for my project.
I’ve wondered what I want to do with the game when I’m done. I’m not a competitive person by nature (or else I’m overly competitive and have pushed through the other side of it). I like the excitement here when a big event rolls around, though.
I appreciate that you (and the others, too) took the time to discuss your experiences. It’s definitely helpful hearing about them.
If I haven’t played your first game yet, I will soon!
I’m not competitive, either, but I love entering the comps. Even EctoComp where I placed pretty low was an excellent experience. In my very limited experience, entering a comp is the way to get lots of feedback, which I think is pretty important for your first game. Come at it with no expectations but getting feedback and learning from the experience, and entering a comp is a really valuable time. The camaraderie and goodwill of all the authors toward each other is really a thing of beauty.
Yeah, I think that’s fine – honestly, while there’s definitely a correlation between a game’s quality and its place in a competition, there are also significant extrinsic factors that can swamp things (comedy games tend to do better than serious ones, longer ones do better than shorter ones, traditional ones tend to do better than experimental ones, etc.), plus the difference between places can be very minor and depend on only a few idiosyncratic voters. So IFComp might actually be a little frustrating if you’re a competitive person! But it’s a fun experience and a great way to get folks to notice your game, so if you’re the kind of person who’ll feel satisfied with a couple reviews indicating at least a few people really dug your game, I think it’s super rewarding.
The postmortem for Past Present goes into my thoughts around building it, so I won’t repeat that here.
The deadline of a comp (in my case, the Winter TADS Jam) was an important part of the process, and kept me focused on finishing the project. So, I would add to the above that comps and jams serve as a good way to keep one motivated.
I’ve said elsewhere the Past Present is my first computer game, and that the impetus for finishing it was to complete a lifelong goal of writing one. Recently I remembered I coded a Core War implementation many years ago for the Atari ST. It’s not interactive fiction, though, and I didn’t design the game’s rules, merely ported it to the platform. Still, in a technical sense, it was my first game. (And fun to write.)
Give 'em a lighter and everyone’s a firestarter. How many variations on “Maybe you shouldn’t burn the carpet/curtains/ballgown/dwarf lady,” can one person think of?
LOL yeah tell me about it I came in 70th place in 2021 IFComp, and the only game I beat was a non-IF graphical card game ffs
As for writing my very first game (not submitted to any contests), I think there were two things that I took away from it. Keep in mind that I write choice-based IF as opposed to the parser stuff.
It’s very difficult to understand the difference between authoring linear prose (a novel) and IF, especially getting away from the “railroad” aspect that is the backbone of all linear writing. In other words, your beautiful narrative arc can be smashed to pieces by the players, so you need to arrange all of the beats differently so they’re more “stand alone” or “self-contained”. Also, the speed at which characters are developed and plot lines are revealed feels 10x faster than a traditional novel, yet good writing of the old-fashioned kind is what makes that lasting impact for the players of IF.
Interestingly, the “game” elements (as opposed to “story” elements) seem to come intuitively, even to folks like me who aren’t big gamers. I think we just all know what a fun game feels like. That being said, calibrating the game elements to get the right amount of tension between the player’s ability to succeed and fail is where the work is. It took me a solid two weeks of jimmying a handful of starting values to get one of my games to hit that sweet spot of “I can beat this, I know I can!” Honestly? It’ll put a tear in your eye when you watch someone play your game and it’s calibrated right.
I generally believe that I have a good idea of this, but sometimes I feel like a bit of a flake with no idea what people like or think.
This second thing, though, the calibration–I am already wrestling with this. I think there has to be a honeymoon period where players learn the systems and their potential before ratcheting things up a bit. I agree that getting difficulty right will be the trickiest part.
I had some notes and ideas for my first parser fiction but, after dipping into Inform 7 and implementing one of the mechanics (following the approach Emily Short called prototype the hard part first), I realized that I would never finish the full-length game.
So I developed the main mechanic completely and then built a minimal story around it. The result was a very compact one-location game that I still like a lot. I used this game twice as a pilot run: first, building and shipping a complete parser game, and second, entering an IFComp (an English version did quite well for a game of its size in 2020).
A good piece of advice is that shipping is a feature, so it’s better to start with a small project, and to not hesitate to reduce the scope if you feel you can lose your development momentum.
I came in 70th place in 2021 IFComp, and the only game I beat was a non-IF graphical card game ffs 