Jump to content

Site Work Failed, But We Didn't Die

Ugh. Still more roadblocks. Need to get an as-yet unknown password from Nay in order to get this sucker changed. For now, please enjoy the mess of a forums we've got, and dream of the forums we will probably never one day have.

< 3 - Tay

You can dismiss this alert by clicking on the "X" button

icecrack

Members
  • Content count

    11
  • Joined

  • Last visited


Reputation Activity

  1. Like
    icecrack reacted to tymmur in What are best practices when designing and programming a VN?   
    This time I will write about my main field of expertise: programming. It's entirely different from the previous post (planning the story) and as such justifies splitting the two topics into two posts. This post assumes using Ren'Py, though it should be doable with most or all engines. I just had to make a choice if I write specific keywords.
    First of all, don't be afraid of adding more files. Ideally you should use a one file, one task approach. Also name the files in a way that allows you to find them easily and use a folder layout if possible. You need to split between setup, file access, flow control, story etc.
    Setup
    Make a file where you list backgrounds and their filepath. Add spaces to make the paths align on top of each other. That way it will be easy to spot typos in the paths. Do the same for music, possibly in the same file.
    Next up is characters. Make a list of characters (possibly in a new file) and assign names, color etc, again with spaces and an aligned layout. Add comments at the end of each line to write the color in human readable text (as in not the color value numbers). Also list the characters to set sprites for each. Possibly do it in one file for each character or in one file, but then sort them alphabetically. You should sort them in the same order as the first list, but it's a good idea to keep the names and colors as a list to get an overview.
    Make a file with sound effects using the same approach.
    If you do this right, you have some files, which list all the media files you use. No other text files access media files and changing the media files can be done from the setup files only. Also the setup doesn't contain much other data than shortcuts to the media files.
    Story
    For each scene, make one file. If done right, it's close to one file for each paper on the board, but in some cases one paper-one file is not the best option. Start with a label, name it the same as the file and name the file something fitting. End the file with a return. Write a story where it's just the story. No jumps, questions or anything like that. All the media file usage comes from the setup files and nothing is called directly.
    Each file should set the scene, like setting music and background at the top and clean up as in removing all sprites at the end as well as canceling all audio and leave the screen black.
    Asking questions to the player and branching accordingly contains some exceptions to those rules. More about that later.
    Flow control
    Make one file containing flow control logic. It exploits the difference between jump and call. Simply put, call will go to a label and when it encounters a return, it will go back to the line it called from and continue from there. Jump will not go back, meaning if you call and then jump, the return will go all the way back to the call.
    Now you should add a call to each label in the order you want the labels to be called. Since each event file ends with a return, the story will return to the flow control and move on to the next line. This way the order of events is purely controlled by one file and is not mixed into the story.
    Questions/branching/flags
    In case a question is asked, return just before asking it. Next you ask in the flow control and branch according to the answer.
    You need to make labels in flow control and when you get the answer from a question, you jump to a label in flow control and continue from there. Since you aren't going back, jump should be used and not call. Each such labels will then call an event and since the screen should not be black while the question is asked, events ending with a question and those starting with one should skip cleaning up and setting up and just continue. This is the exception to the cleanup rule.
    If you want to use flags, you set the flag in flow control and you test for flag conditions when figuring out which event label to call, which is also done in flow control. This way you have all flags and actions based on flags placed in the same file.
    Testing
    When writing an event (story), just add call scene after start and testing it will be quick and easy. This will allow testing text, sprites etc without having to consider flow of the story. It's a huge timesaver to not have to fast forward to the scene you work on for each change you need to test. Naturally you should test the VN in the final form before publishing, but you will likely do a lot of small tests multiple times a day while working on it to catch typos and similar as early as possible.
    Final words
    If you follow this guide, you will end up with a layout where each file has a purpose and it's easy to tell the parts apart. It helps a lot of you want to swap the order of events as this can be done without touching the story itself. Likewise you can't break the flow control by accident by changing the events and changing which media files to use will not affect either. In other words it's a design, which heavily reduce the risk of bugs and it also reduce the need for testing after making changes.
    Now put those two posts together and make sure you have at least one paper for each event file. However in some cases it might make sense to merge multiple papers into one event file. It's something to consider in each case and I can't tell you in general if it's right or wrong to do it in your specific scene. It's one of those things you have to figure out on your own.
  2. Like
    icecrack got a reaction from Zander in Sup madudes   
    I expect great things, welcome aboard
    Sadly this is true for many of us, last time I tried to draw... *shudder*
  3. Like
    icecrack got a reaction from Plk_Lesiak in Heya Fuwa community   
    Hello everyone, this account is almost 2 years old so I'd say an introduction is long overdue.
    I watch anime and read VNs whenever I can. Right now I'm learning Japanese so I can one day help more VN goodness come west.
    I hope we get along and you can use this post to ask me anything cause I don't really know what else to say.
     
  4. Like
    icecrack got a reaction from Plk_Lesiak in Heya Fuwa community   
    It's been a while and I'm still crying
    That's a nice suggestion and I'll get to that asap.
    Thanks everyone for your recommendations and for making me feel so welcome.
  5. Thanks
    icecrack reacted to tymmur in Heya Fuwa community   
    It could be worse. I realized I forgot to make an introduction after being active for 2.5 years
    Musumaker
    Majo Koi Nikki
    As for VNs, where the English translation have actually been released, the first, which comes to mind is Kamidori and then the Rance series. Sexy Demon Transformation is hilarious and fun to read despite being a nukige.
  6. Like
    icecrack got a reaction from Plk_Lesiak in Heya Fuwa community   
    Hello everyone, this account is almost 2 years old so I'd say an introduction is long overdue.
    I watch anime and read VNs whenever I can. Right now I'm learning Japanese so I can one day help more VN goodness come west.
    I hope we get along and you can use this post to ask me anything cause I don't really know what else to say.
     
  7. Like
    icecrack got a reaction from Plk_Lesiak in Heya Fuwa community   
    Hello everyone, this account is almost 2 years old so I'd say an introduction is long overdue.
    I watch anime and read VNs whenever I can. Right now I'm learning Japanese so I can one day help more VN goodness come west.
    I hope we get along and you can use this post to ask me anything cause I don't really know what else to say.
     
×