Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

How long does a twine game usually take to make?

edited November 2015 in Chit-Chat
Ok so i'm wanting to start a project and it's going to be a really large thing I'm just wandering hw long it might take me

Comments

  • edited November 2015
    That all depends on a number of things. For instance...

    Is the gameplay going to be as simple as moving from one location to another, or are you planning on having complex scripts and variables for object collection, etc?

    How many routes to the end do you plan to have? And indeed how many endings?

    Do you have any coding knowledge; JavaScript, etc?

    How long are your location descriptions going to be, short and sweet or detailed and full of atmosphere?

    How much time can you dedicate to the project?

    How large is 'really large' ?

    It really is impossible to answer. It might take you a month. It might take you 6 months.

    When I last had a stab at making one of these, I was using a program called Quest. This was a traditional input style text adventure and was fairly complex. It was free-roam to a large extent and required the player to discover passwords and other objects before they could access certain routes. I worked on it most nights for a few hours and probably got as far as 70% or so before running out of steam and abandoning the project.

    I think I was at it for about three months or so.
  • Well, to start with I'm going to try and have pictures in it. Like a click game you click different parts of the image and it takes you to the next and the next. all possible routes will lead to one ending. as far as time goes I could work on it maybe a few hours a night.
    Javascript knowledge; I have hardly any but was going to learn as I go.
    Does any of this information sort of narrow it down?
    Really I wouldn't mind how long it took I just had a good idea and wanted to see it come alive.
  • How long will it take you to complete each picture, and how many pictures do you think you'll have? Add whatever time it'll take you to plot out the entire thing, then some more for you inevitably changing stuff from what you learn implementing it. Will the game have any words? If so, roughly how many? Hundreds? Thousands? Ten thousands? Use that with how much you can comfortably write every night. If you're not a regular writer or artist expect those things to take time to learn and develop habits for. Anticipate that you're going to want to give up because it's a lot of work, and make sure you're ready to push through that.

    Ultimately knowing how long something is going to take requires you to know how much work there is to complete. That's the first thing you should spend time figuring out. Also try to make something really small (and I mean really small) first to get a hang of exactly how much work goes into each piece.
  • I'm echoing what Jud_Casper and brwarner have said, there's no set time for it. Think of writing a game (and this goes for any game, not just Twine games) as a production line. If you have several workers on the production line then the production line will go quite fast. If you're having to do everything on the production line then it's obviously going to take longer (unless you're an octopus, have a load of computers and are exceptional at multitasking :) ). There are little things you can do that work quicker and you'll learn little shortcuts or ways to do things better/quicker as you progress, but you still need to do them regardless.

    Something I'd strongly advise against though is trying to do it as quick as possible. If you do this then you may well end up with a game that looks rushed or full of random features (aka bugs).

    I'd start by first of all developing your story/plot and write out the 'core' of the story. This is pretty much essential as you'll have your start, middle and ending(s). You can try and wing it or make it up as you go along, but you can end up with a situation where you've done something that contradicts an earlier event, contains a massive plot hole or doesn't make sense.

    After you've done that, ask people you know (not internet friends because at this point your idea is in the wild and could be stolen) would they mind reading it and giving you some honest and constructive feedback. This is really important because it allows you to gauge whether it's worth proceeding. Not to put a dampener on your idea, but there are also some things that need a linear narrative and can't work if the reader needs to make decisions.

    After that sit and plan it all out, and make a diagram of where you want to go, what you want to do, side quests or sub plots, and anything else. When that's done try and make timeline of what you want to complete and set yourself a realistic date to have it done by (don't get disheartened if you fall behind though). When you set yourself a milestone, give yourself a little treat to go along with it because it then gives you something to aim for.

    Something I do quite a lot is use KeyNote to write character synposes, any lore I want in the game, write designs for certain things and whatever else. It's free and it allows me to write stuff down in a format that I can access easily as opposed to wading through a small mountain of files or notes in a folder.

    At this point it's probably a good idea to start deciding which format you want to use. If you're doing something fairly simple then the built in formats are fine for that, but if it's advanced you may want to use SugarCube, because it has a lot of features that the standard ones don't (and is my preferred story format). With this, the KISS (keep it simple stupid) approach is best. Just because a format can do somethings others can't, it's pointless if you're not going to use them. Although I use SugarCube, if I just wanted to play some music in the game then I'd use a macro and a default format.

    The KISS approach can also apply to the actual design of a game. Just because a format will support something or you discover a really neat routine, it doesn't mean you have to use it. Sometimes sticking to the bare minimum of features can be best as everything won't appear too busy. You may have the best story in the world, but if it's an all singing, all dancing mess then people will give up because they're getting a headache.

    Stay focused as well. If you're writing a routine to deal with combat for instance, don't drop it half way through and go and develop an inventory, and then drop the inventory and go back to it. If you find a routine is boring you to code (and some of them can be really tedious to code - I wrote a generator for 100,000 names and that was tedious because I needed to format the names list (although Notepad++ was great for that because I could record a routine) - leave a /%comment%/ at the point you leave it with what you're doing and then put it all away for a bit. Don't try and do something else. The reason for this is the fact you'll get fatigued and once you end up in a state where you get fatigued you'll make mistakes, take shortcuts and it will stop being fun. Recharge your batteries and then come back to it.

    On that note, it can sometimes be useful to test out little snippets of code as separate things before you put them into you main project. This way you can see if something works without all the hassle of putting it in and then realising that it doesn't work as expected, or in some cases actually breaks something else you've done. Oh, and remember to make backups when you're putting something new in.

    You also need to understand the limitations of what Twine and Javascript can actually do. Will you make GTA V? No. Can you make really absorbing stories or point and click adventures? Yes. Each language and engine has their own limitations and advantages, and you may find that Twine can't give you your end vision, so keep that in mind.

    As others have also said, it depends on the scale of your project. The name generator I linked to took me around 12 hours to complete, but that was mainly due to the formatting of names and the actual coding was a doddle. One of my current projects has been in development for the past 18 months or so (based on an idea I've had for around 20 years and is a double trilogy - not a sextology as each trilogy stands alone, but they are linked), and about 3 months of that was purely the planning part of it. There's been a few times I've sat there and thought I've done not much. While I've only got the character creation system and the first few areas done from a play perspective, I've done routines that allow me to shrink approximately 3200 passages (assuming each passage would be a location) down to around 100, although there is a lot of code running in the background that keeps check on various things and where you should be in the game world and modifies templates accordingly.

    I hope that helps.
Sign In or Register to comment.