One of the most tricky aspects of amateur game development is just working out what workflow you’re going to use to get from point A, your germ of a premise, to point B, the finished game you can release. (This is not always as much of a solved problem in commercial game development as one might expect, either, but a commercial project tends to have some people with prior experience shaping a game who have a plan — whether or not it’s a good plan — about what needs to happen in what order.)
Lately I’ve adopted a new approach to this, and it’s made me look back on how I’ve done such things in the past, and the whole gory evolution (which is probably not over yet) of my implementation strategy.
Implement first! Design later!: You open up your IF tool of choice and you just go. Implement a room or two, some stuff to go in it, maybe a character. Write whatever comes into your head, then seek out the connections that come out of it.
In my experience, it’s really hard to finish this kind of game. I’ve started lots this way, especially when I was new to IF writing, and that was all useful experience because it familiarized me with my tools and was a kind of play. But sooner or later you hit a wall where you realize that your doodlings aren’t going anywhere and you have no particular end in mind; or you do, but there’s not a coherent plot, the backstory doesn’t work consistently, the pacing is off. No design intentionality has gone into the project, and sooner or later that becomes obviously a problem. At that point you can either ditch the project and start a new one, or step back and do some intentional design work on the project, then come back to implementing.
There’s a real risk, though, that if you’re alternating implementation with incremental design you’ll let yourself consistently avoid the really difficult pieces. “Ending goes here.” “Something interesting happens, I’m not sure what, and the player winds up at Alpha Centauri.” “A coding miracle occurs because I have no idea how to do this.” You may not even realize that you’re doing it… until sooner or later you realize that thing is just not getting done. And isn’t ever going to.
Prototype the hard part (usually a game mechanic) first: you figure out the most important/difficult simulation elements in your intended game and code those, working on them until they succeed; then work out the puzzles that go with it and build up a game from those.
I fell into this approach accidentally when Implementing First ran out of steam. I was working on a huge sandbox game, my first real IF project of any scope, that involved a detailed implementation of cutting and burning; a polaroid camera that recorded object states accurately including that of things that had been cut and burnt; smoke that smudged things; mixable liquids and varying light levels; goal-seeking conversational NPCs who responded not only to discussion but also to a large number of gestures and to observing when (e.g.) the player destroyed important objects in their presence. (Ten years later I think I might finally know enough to be able to code that game. Alas, I no longer want to. The gameplay concept was a total mess.)
It was too hard to prototype the conversation system and the materials modeling system in the big game, so I went away and wrote little lab-test game versions of them, where I developed the system first and then implemented some stuff with it. The first of those lab-test games became Galatea, the second Metamorphoses. For a while I told myself that I was going to go back to the big game later, but I couldn’t help observing that, unlike my original approach, this one was actually producing things I could release. I decided to keep that “Implement First!” approach as a form of brainstorming — I do still sometimes mock up a few rooms as a way of getting rolling envisioning a new setting or establishing a mood or PC voice — but not rely on it as my main methodology.
The thing was, though, that prototype-hard-stuff-first was still producing a lot of time-wasting. Metamorphoses was originally a much, much bigger game and then had to be ruthlessly cut down to reach its final size — entailing a lot of discarded code and design. I decided I needed a more top-down approach.
Fully design on paper, then implement: You sit down in a coffee shop with a notebook and you write down everything you need to know for your game. Maps and puzzle diagrams, if it’s that kind of game; plot plan and lists of scenes, if it’s that kind of game. Character bibles, historical timelines, setting research, if it’s that kind of game. (It may be all of these at once.) Then you code, checking things off on your plan as you go until they’re all done.
This is pretty much how I did Savoir-Faire. The setting came out of some freeform brainstorming sessions with Inform, and I did prototype the magic system first; but then I sat down and made a list of puzzles, arranged them into a big chart, and implemented the chart. This was hugely satisfying as a process because it produced a sense of forward movement. I knew I was making progress and I had a pretty good idea of when I was going to be done. I tweaked the design as I worked, a little — there were a few puzzles I decided were too arbitrary and threw out, and in response to tester feedback I extended the early game to contain some easier puzzles because it was generally thought to be too hard to get into.
I’ve never had that approach work quite as well again since, though. Generally the failure is down to one of three things:
Lack of self-discipline in the planning phase. I let myself get away with making a chart that still had some fuzzy bits in it, some magic I meant to tackle “later”, and of course later those things proved intractable, just as much as when I tried to implement with no written plan at all. A particularly seductive thing is to do a classic three-act structure and only design the opening and the midgame, leaving the endgame for “later”. Reasons this is terrible: it sucks to have 2/3 of a game completely implemented and be staring at the prospect of not being able to finish it after all; and then sometimes you can finish it, but your solution for the endgame is bodged together and lame compared with the opening and midgame, which is sad when you (and your players) were hoping for a strong finish.
Disproportion of effort, skill, or other resources. It’s very likely that you’ll wind up working really hard on the first stages of the game and getting them into good shape, maybe having them alpha tested before you’ve started the endgame. Even if you have the end fully plotted, you may find that you’re running out of energy, time before a competition deadline, and/or beta-tester attention by the time you get to it. Or, on the other hand, your skills may have changed substantially by the time you get to writing the endgame with the result that the end is actually much better than the opening — but not that many people actually get to it because they were put off by the ineffective start. I’ve played games of both kinds, and written several of the first type. (I’m not sure any of my games finish stronger than they start.)
Slightly different problem, but along the same lines: Savoir-Faire was running out of storage space in the game file by the time I wrote the last puzzles, which is a reason why they may feel oddly spare compared with the rest of the thing.
Overambition. You write a big chart, and it looks cool, but as you code you realize that it’s much, much too big and your energy and interest aren’t going to hold out that long. You can perhaps salvage by attacking the design and cutting it down to something manageable — I’ve done that many times — but there’s still a bunch of lost effort in the process, things you coded and can’t use, puzzles you worked on and have to ditch. This hurts most if you’re ripping out bits that you really liked. Earlier drafts of Floatpoint were both more puzzly and more comic, because I wanted to emphasize how much the protagonist was out of his element by having him struggle farcically with native customs and machinery. I had several bits on this that amused me a lot. But they had to go in the end because they made the game too slow to write and too long for the competition, and because they distracted from the real thematic points of the piece. I was pretty sad about taking them out. If you can’t bring yourself to make those cuts, though, the project may stall out entirely.
So now I’ve gone to:
Write the through-line first: come up with your setting and any prototype coding you need to do, and maybe make a list of puzzles/elements that you’d like to see in the finished game. Then create a simple outline design of the game and implement it so that you have something you can play (even if very quickly) from a beginning to the end, and which contains the most critical turning points of the plot. With that skeleton in place, consider what you like and dislike about the structure; you complicate the game incrementally, fleshing pieces out with new puzzles or improving on the simple puzzles/conversations that you used to start with. You may be drawing on the list of puzzles or situations you’d had in mind to start with, but you don’t have to commit to a whole structure at the outset.
What’s great about this: by the end of the first week or so you have a complete playable game. It is always in some sense “finished” — oh, not in a state you’d want to release, certainly, but it has a clear enough shape that there’s not a horrible anxiety-producing mystery about what will go in any part of it. The ending gets as much attention as the introduction, and isn’t likely to be fundamentally different in style, theme, or implementation quality.
At the same time, you’ve got a process with a lot of flexibility, because you can add new elements to address design flaws you see. Too steep a learning curve? Fine; add a few more intermediate puzzles to the opening of the game. Not enough motivation for a major NPC? Add another conversation scene that sheds some unexpected light on her background. (A weird thing about IF: it’s generally easier to add stuff than to take it out. If you’ve implemented a major feature or a complex puzzle it may have implications here and there throughout the whole code. Editing it back out is like kudzu eradication and may leave you with bugs.)
Finally, this process offers the best odds for return on investment. At any given phase of development you’ll have something that you could stop, beta-test, polish, and release. Doing that early might produce a bite-sized mini-game with little story complexity; doing it late might produce a 15-hour masterwork; but the process of getting from what you have to a game you can release is always clear.
This is the method I stumbled into with Bronze, largely because that was a Speed-IF I decided to flesh out into a full game. I’ve come back to it for another WIP I was having trouble with, and I’m finding it very liberating.
I’ll probably find things wrong with that, too. But it’s working for me better than any of my previous approaches to date, so right now, that’s where I am. Writing the through-line first.
There’s another possibility I should mention:
Transcript fully, then implement: You sit down with a text editor and you write the transcript of your player’s perfect experience. Then you implement that.
I’m throwing this in here as an alternative because though I’ve never done this with a full game, it sounds like a viable process. J. Robinson Wheeler has used it; he talks about the process in some detail in his Make IF Fast article (now missing from its original location but available via Internet Archive here), and Stephen Bond writes about applying this approach to The Cabal. A real strength of this approach is that it encourages the author to think like a player: to write in the hints and subtle cues in the output that provoke exploration, to create a strong sense of pace. I don’t think it’s coincidental (a) that Wheeler is a sometime independent filmmaker familiar with writing screenplays and turning them into a finished form; and (b) that the games he describes writing this way are among the most cinematic and smoothly forward-moving I’ve encountered.
Emily Short's Interactive Storytelling 
Thank you! This is incredibly helpful!
Excellent article; I find it especially interesting in its parallels to the ideas of prototyping vs. planning in graphical video games.
Did you mean, though, for your diagrams to be as tiny as they are in the article? Could you link to larger versions of them?
They’re really just meant as sort of icons of different approaches, but if you’re interested in the full diagrams (together with a much fuller description of the process of writing Bronze), they’re lifted from here.
This is easily the best IF article you’ve ever written. It’s informative, insightful, and offers some very useful advice that I should have heard long ago. I’m currently stuck between stages two and three; I’ve already bookmarked this page in the hopes of getting to stage four as quickly as possible.
What you’ve come across is agile software development. The traditional waterfall model where you fully design, implement, integrate, then test, doesn’t work. In software, your understanding of the problem is constantly evolving. More modern techniques often involve shorter design-implement-debug cycles, where you release early and release often.
Prototyping can work well, but the object there isn’t to make a demo so much as to prove a point. You want to get a prototype done quickly, and throw it out when you’re done with it. Too often the prototype becomes the (shoddy) end product.
You might be interested in extreme programming. It got a lot of hype 10 years ago, but it involves some practices that work well, like test driven development and pair programming. Most software engineering is about getting teams to function, but you’ll find it much easier to code on your own if you try to write as if someone else is going to maintain it.
I’ve read a bit about agile software development, and about test-driven development. I can certainly see the similarities in philosophy, but my impression was that a lot of agile practices had to do with team management, which isn’t the main issue here.
As to testing… hm. I do a certain amount of this, especially with Inform 7’s “test … with…” syntax, in that I will often write up the sequence of commands that will demonstrate success at the same time that I write the code. But I think that’s only meaningful for certain aspects of IF implementation, since in addition to the technical “does it work?” stuff there are a lot of design considerations and narrative considerations that cannot be done to a test target.
Pair programming I don’t know much about.
Pair programming is where two people sit at one terminal. One types, and the other watches and keeps the typer on task, something like a master-apprentice relationship. I’ve never done it personally, but I know people that swear by it. It’s supposed to be fun.
Techniques like this are less relevant for games, because they’re much more complicated and don’t need to be as error-tolerant. Especially for IF since it’s so individual.
But there are some ideas that could help. For instance, to develop your conversation system, you could have done some quick design-prototype-test cycles, getting more detailed with each prototype, and testing live with real people. That sort of process is a proven way to work out user interface design–you get feedback early and often, instead of having to make guesses based on transcripts.
The prospect of having someone sitting at my shoulder commenting while I type makes my fingers twitch for a baseball bat. I don’t think that would be a happy scene.
For instance, to develop your conversation system, you could have done some quick design-prototype-test cycles, getting more detailed with each prototype, and testing live with real people.
Conceivably, if I had the resources to hire real people every other week.
Well, one of the core concepts of agile development practices is rapid iteration. The idea is that you work in short bursts with well-defined goals, and take time at the end of each iteration to evaluate your progress and decide what to do next. You plan the iterations so that at the end of any iteration, you can stop and ship the product, even if it’s missing some features. So that’s pretty much the line-through-first approach you described.
The kind of testing you mentioned is pretty close to test-driven development. One difference is that in TDD you’re supposed to write the tests first, and then write code until it passes the tests.
I think most other agile practices are overkill for solo hobbyist developers. They’re about keeping open lines of communication between developers, managers, and clients and making sure everyone has a clear understanding of the project’s goals and status.
A very inspiring article, thanks for posting. I approach the illustration process the same way, shortcutting as much as possible to reach something that “feels finished.” Then I go back and fill in details. A very helpful approach under deadline.
For what it’s worth, I design everything on paper and then implement. And I implement in forward plot order. So at any stage I have a fully *polished* partial game, which starts at the beginning, runs up to a given point, and then stops dead.
This turns out to be what I need to keep going. If I tried the “through-line” model, my momentum would be stunted by the feeling that no piece of the game was ever (or would ever be) done.
My prereqs are (1) having a good idea of how much work every piece will be, so that you don’t discover halfway through that you’re only one-tenth of the way through. And (2) a lot of bloody persistence.
(Although since I haven’t finished a game since 2006, you *could* argue that I need a new strategy.)
(“Let the Wookiee win.”)
For what it’s worth, I design everything on paper and then implement. And I implement in forward plot order. So at any stage I have a fully *polished* partial game, which starts at the beginning, runs up to a given point, and then stops dead.
This is my process, too. With a through-line process, I would be constantly harried by the temptation to just stop where I am and release, thinking, “Well, at least it’s playable, even if it’s not as full as I wanted.”
I’ve clunked through a couple of these processes and produced garbage as a result. However, the “write the full transcript first” approach is now working *beautifully* for me and a collaborator. He wrote a great transcript with a fun plot, and that instantly sucked me in to start helping with the implementation. It feels more like a real work of fiction now, rather than just a “program”. It was born with a tangible soul, as it were, even before we wrote a line of code. I’m going to use this technique from now on. :-)
Your recent design articles would be wonderful as a part of a game design book. These are some of the best writings on interactive fiction I’ve read.
Mmhhh, I do not agree. Like in software development, the methodology is a fashion… Waterfall, Test Driven Development, Domain Driven Development and more…
It’s a fashion if people adopt a method for some reason other than utility — on a big project I can certainly see teams having some method forced on them by management following the latest trend, but one of the nice things about being a solo author is that you really can pick whichever approach works for you.
Given I’ve gone through all the same methods so far, except the last one, and with similar results… I’m eager to try out your new find, as it sounds like it could be the optimal way to do it :) Thanks for this article!
I’ve read the “implement fully” advice a couple of times, but I can’t quite bring myself to do it. Partly because the creative work is fun for me, and the coding isn’t – or it’s a different kind of fun, one that I seem to crave more occasionally. True, at least with IF there’s likely to be different sorts of coding opportunities – writing the magic coding is different than synonym searches.
Still, even when I’ve tried to think ahead, I frequently find myself adding things. What if the player pushes the car? What if they try to burn it?
On my current project, which is the first one that I hope to release at some point, I’m working for the 80/20 rule: have 80% planned, implement 80% of a location before moving on, but give yourself leeway to add/subtract/modify things.
I do find it helpful to have a few things fully in place, the most important of which is who characters are and what they want, since changing that requires the most overhauling of a text (for me, anyway.)
thanks for this, Emily!
reading it, i wonder if a new IF writer is highly likely to move through the processes in more or less the same way you did. i’m currently messing around, writing something very haphazardly and i’m definitely doing the “implement first! design later!” thing. i had an idea for a concept and i said “eh, let’s try doing something with this.” and reading your suggestions, especially about your current process, i found myself thinking, “this sounds really great, but if i’m not sure i could actually work this way right now, because i’d keep getting stuck and sidetracked by things i haven’t learned yet.” i think maybe i need to flail around for a bit. i’ll definitely be bookmarking this post, though, to check out later, once i’m ready to get serious. :)
Thanks for the insightful article. It is always fascinating to me to hear what does and does not work for others.
I feel like perhaps, at the end of the day, there is a place for all these “strategies.” People (including myself) are always trying to find the “optimal” strategy to code, or make a game, or write fiction, or whatever, but it seems that a) what works for one person may or may not work for another, and b) even what works for me sometimes doesn’t work for me, and sometimes what doesn’t work for me does, and sometimes I just NEED to let off steam by “implementing first,” or I just NEED to sit down and think about creating a world from the top down, or whatever. Even if I know I’m not producing anything that will ever be a “finished product.”
I guess what I’m saying is that the creative process, in my experience, tends to be a living, breathing thing, with a mind of its own, and various appetites, and a bit of a mystery.
Not that this at all negates the usefulness of strategies, or the necessity of finding what tends to work best for you. The through-line approach, I think, is a very helpful one.
My goodness, I think I’ve used every one of those strategies on my WIP at one point or another. Some bits I had absolutely no clue how to do, so it was Implement First, Design Later all the way (and included the requisite re-writing of that bit two or three times over). There’s the Hard Game Mechanic that I’ve been working on for seemingly forever. A few bits of the WIP have been Fully Designed Then Coded, though I only sometimes feel there’s a gradual sense of progress; other times I feel I’m just “creating by numbers”. I used the Throughline when going over the high-level writerly bits and scene-creation, and that certainly works… though blandly because Core Gameplay Mechanic isn’t quite ready for primetime. And I’ve even used Transcript Fully in a few cases, though in a check-your-work kind of way. (Later I’ll use it in a polish-the-game way).
I have one thing that ties all my madness together, but I don’t know if it’s a strategy or tool or what — the dev diary. Though its narrative bounces between hard drive and paper, it’s about what it sounds like: dated entries of myself talking to myself about what I’ve done, what I’ve to do, and what I should stop trying to do cause it didn’t work two months ago and sure as heck won’t work now. It really keeps me sane and on-track. Occasionally it’s my best friend, because it has answers tucked away in back entries. And occasionally it’s a riveting piece of creative non-fiction, as I empathize deeply with the character of Younger Ron: his elation of a tricky bit conquered, his despair about the backup failure of ’08, the inscrutable mysteries I know he will soon unlock, etc.
I think I generally use one strategy until I hit a wall with it, then try a different tack for awhile. But the diary is why I can do that without losing focus.
Oh, and lest anyone believe that Prototype Hard Bits First or Implement First Design Later are poor ways to go about creating a game, remember that other good works emerge from those methods best. For example, a prototype could be polished for a useful extension, and writing up your experiences flailing around, as a tutorial or as a humorous essay, throws a rope to the next person who flails in the same spot.
I’ve taken both of those paths, and when someone thanks me for this extension or that tutorial, the motivation to continue the true purpose of it all, the WIP, increases substantially.
This was a great article. I’d stumbled through the first few of these modalities already; it’s nice to see that the approach I’m using now (the through-line approach) has produced good results for others as well.
Thanks!
@brian: My experience has indeed been that I’ve been moving through those stages, in about that order.
I never did a completely exhaustive design as she describes for Savoir-Faire (too lazy), but I did do a bunch more up-front planning. Other than that the progression seems spot-on to me.
For Everybody Dies, I started with a puzzle/plot sequence on paper for the structure and followed up with a transcript to get the tone/characterization, and left implementation to last — once I was sure I had a solid, interesting game (and the illustrator came on board after seeing the transcript).
But I bet if someone was more confident in their programming than writing skills, the opposite tactic might work better — putting your best foot forward gives you momentum.
This wasn’t the case really with ED, but with most of my novels I’ve rewritten the beginning after I’ve finished the ending. That way I don’t get inhibited by creating the “grabber” first page when I start something, and by the end I have a better assortment of things I can foreshadow.
Russian translation: http://tinyurl.com/3ylj5h4
Huge thanks for the article. Useful for self-development. :)
I’m hitting walls in pretty much all of my creative endeavors, not just the eternally unfinished IF attempt(s), so dug around miserably and read this. To my surprise the “throughline first” method sounds a lot like what I’m trying to tell myself to do, although the catch is that after putting in a few parts of the skeleton I become filled with acute revulsion for both it and myself and start fiddling with trivialities rather than face the revulsion. Or just do other stuff, hence eternally unfinished.
Take heart it should be that I do from the main body of this post, which chronicles after all some difficulties even of an august author/designer. For without understanding the degree of complexity involved in fully fleshing out and implementing any given mechanic, can a proper understanding of the scope of one’s project be reached? No experiential reference points to rely on, not enough familiarity to estimate and (pre-)evaluate. I won’t be writing the next Galatea, but if only I can keep struggling on long enough, perhaps I can just write one. Damn. Game.
This has been your six-years-later necropost of the day.
the catch is that after putting in a few parts of the skeleton I become filled with acute revulsion for both it and myself and start fiddling with trivialities rather than face the revulsion
I know the feeling you’re talking about. You’re not alone in this.
Sometimes one can fake a way through by writing something incredibly tiny, like a 200 word Twine or a single room environment, something really fast before the inner critic has a chance to start being too much of a jerk. Or doing a project that is really really really constrained (“I’m going to edit this existing open source thing to add one tiny feature”, “I’m going to make a poem using only words I cut out of page 53 of this Babysitter’s Club book”): that can sometimes work too.
Sometimes I also find that the problem is that I’m trying to implement or write something before I yet have a clear enough idea of what I want to accomplish. In code, that means I haven’t got good specs yet. In writing, it means I don’t know the plot or the characters well enough to bring them out in prose. In that case, sometimes I need to put aside the laptop and everything else and sit with a notebook — or even sit in an armchair with my eyes closed — just imagining the output in as much detail as possible. I’ve made key progress on projects sometimes while to all external appearances I was asleep on an airplane.
But if simplifying or re-envisioning the goal is not producing the kind of breakthrough you need, then this may be about the emotional landscape rather than the project. In that case it takes some mind-hacking instead.
I’ve tried: free weights, CBT exercises, alcohol, Eminem on blast, talking problems out with sympathetic alpha testers, cardio, setting small objects on fire, crying, chocolate, dance, taking a break and coming back to it later, working on it mercilessly without sleep until utterly wrecked, going for a swim, baking, shopping, ASMR, throwing the whole project away, walking around barefoot in the snow, writing down exactly what I thought was wrong with the project, changing work venues, breathing exercises, prayer, right-brained crafts, determining to write only for myself, playing five straight hours of Snood, and a few other things.
Please don’t try anything at home merely because I just mentioned it, because that’s not a wise person’s list. I have scars. I’m just saying I’ve done more and less stupid stuff coming to terms with this aspect of the creative mandate.
Lately I’ve had some success in talking things through with myself as though I were a third party. “Why do you feel anxious about this? What are you worried will happen? What are you worried you might prove about yourself?” — until I can start picking specific thoughts and beliefs out of the emotions. They’re easier to deal with once identified.
Also it sometimes helps, when I’m anxious about whether I can do an adequate job on something, to instead decide to do an awesome job on it. And spend a while thinking about what an awesome job of that task would look like and how I would accomplish it, and somehow this jars my thinking out of the “ugh, I can’t, this is going to suck” space into a more positive “here is how I’m going to rock this and figure out the problems I still don’t know how to solve” state of mind. Which is so backwards-seeming, I have no idea whether it would work for anyone else.
Mostly, though, be gentle with yourself. I say this with conscious hypocrisy.
I’ll be thinking about this advice too. Thanks for putting such time into it.
To add to what you’re saying, something I did last year was to give each of my eternally unfinished projects a revision control repository where I could at least describe it with thorough notes. In the process of writing and revising these notes, I’d encounter gigantic rough patches, such as main characters I couldn’t even describe beyond two or three sentences or plot events I couldn’t arrange in a consistent chronological order. If I ironed out these gaps, even on a whim, I would have a rush of ideas about another part of the outline. Like, once I know the tendencies of the characters, I start gushing with ideas about fun, specific things the characters can do, which then tells me what kind of places they would go. That tells me a bit about the economy, which gives me more material for describing how the characters are motivated….
I’m not reaching completion anytime soon, but at least I’m less stalled than before. As I go along, I can set my sights on clipping out self-contained sub-stories and releasing those. Considering my schedule and attention span, the size of story I’m capable of releasing may be far smaller than I’d like, but even the smallest microfiction is a valuable milestone that keeps me from stressing about “One. Damn. Game.”
Thank you for your kindly words and advice, Emily — I’ve been mulling it over all day. I don’t know what kind of mind-hacking would work either… but I will try the rest, and hope that that things may be well for you also.
This is really interesting! Thank you for writing it (and this whole blog, it’s very engaging and accessible– I’ve been bingeing). I’m stumbling into IF hobbyist fun from being a prose writer with a day job doing process compliance in medical SW dev so the lines between plan, draft, and implementation are really interesting to me. For my experience, I’ve been building much more solid plans & prototypes for games than I do for novels– but I think that’s because with novels I don’t have to build the paper or book spine or decide how they turn the pages, and with IF you arguably do. Thinking about it, I think I outline the story itself to a similar degree– establish the big through lines and turning points, and assume/hope/believe the “feelings” will come to life as I go… But I’m only working on my second game as is so I’ll learn and change into new processes and models as I continue!
Thanks for the discussion above– makes me think!