Lemma Soft Forums

There are many of us who are working on our first VNs, and will probably make a lot of mistakes along the way. I'm hoping some of the more experienced community members could share some of the things they wish they had known before they'd started out.

While things like not making the first project too ambitious, establish your name before going commercial and so forth are useful, they've also been said many times.

What I'm hoping to hear about is problems with distribution, legal concerns, kickstarter experiences, planning faux pas, and so forth. Things that us newbies will probably have no clue about.

PS: If there are any related to problems with team members, let's keep it civil and not use any names.

A custom UI goes a long way to making your VN look professional.

Susan

For those on the business angle:

The difference between a hobby and a business isn't that a hobby is for fun and a business is for money.
The difference between a hobby and a business is that a hobby is for your own self-gratification, while a business is for creating and selling products or services your customers want or need.

Confusing hobby and business and not being honest with yourself about your motivations and the true nature of your operation can be tremendously expensive and demoralizing in the end.

Of course, your first VN probably shouldn't be part of a business anyway

Have a plan. Follow that plan.

If your marketing plan consists of releasing here and that's it, you've got my a bad marketing plan.

Just because something has been done before doesn't mean that you can't do something similar. Nobody has done a romantic story about the pen and scissors on my desk, and there probably is a good reason.

There are more types of music than just JPop.

Do you have a plan yet? Hurry up on that.

There's a 0.0000000000001% chance that your first VN is good. Don't give up.

Keep drama out of your team.

Ask for help. If only you or your friends have looked at your script before release time, you're gonna miss something that might ruin it for everyone else who isn't as emotionally invested in it.

Get a proofreader. Poor English skills are not an excuse, find someone whose skills are sharper.

Have I mentioned having a plan yet? Know what assets you need from the start, who is going to be doing what, how long you need, and then stick to the bloody plan!

Have fun with it. If it starts becoming nothing more than an unrewarding chore, it is probably time to take a break for a bit.

"Everything in war is very simple. But the simplest thing is difficult."
-Clausewitz

Has complete application in visual novel development.

At least for using Kickstarter, as far as I know, you can't change the main page once your Kickstarter ends. Neither can you change the rewards once those are up. If you change them midstream, you will sometimes have to answer the same question 50 times in a row.

Think very carefully about that KS main page, because it's burned in stone after a certain point (I believe after the campaign closes). It's going to be what everyone sees who stumbles upon your project because it was on KS. A day later. Months later. A year later.

Unless you're already known and/or have fabulous art, get a prototype of your game or part of your game built as soon as you can, and get a decent amount of feedback for the prototype BEFORE you launch your campaign. For a visual novel, I think that's more important than everything else, including marketing. Marketing comes second.

Think carefully, in general, about what you want to call your game. I don't like the term visual novel. I don't like the term dating sim. I don't even like the term "game" to describe what I'm making. But I use the term I feel will get the most hits when writing that first line in your KS description (and your blog description.) Do a search on KS for different types of games, you'll see what I mean when you get the search results. Terms are how people find you. Keep that in mind when you start doing interviews and updating your blog.

Be really careful with physical rewards. Mailing rolled-up posters can kill your budget.

Talk to other devs. Other devs are smart and funny and helpful and and will keep you from going insane when you start sleeping 4-5 hours a night during crunch time. And they know your pain.

And have fun.

Samu-kun wrote:"Everything in war is very simple. But the simplest thing is difficult."
-Clausewitz

Has complete application in visual novel development.

+1

Obscura wrote:Talk to other devs. Other devs are smart and funny and helpful and and will keep you from going insane when you start sleeping 4-5 hours a night during crunch time. And they know your pain.

I certainly can't argue with that. I frequent #renpy which is wonderful, but due to time zone differences, there can be lulls in communication sometimes. Curious where the other devs are most talkative, especially with group discussions.

Anyway, appreciating the advice. Have bookmarked this topic for future reference too.

What is #renpy? Is that a twitter hashtag or something else?

The Ren'Py IRC channel.

Even if art is your strength, leave sprites until after the writing is at least mostly done. I guess this only applies to solo projects but it can be pretty handy for working in a team as well.
Also, create all backgrounds on the same perspective grid base. That way you don't get fluctuating planes of reality.

Oh, and with kickstarters, I've only been part of one personally but I can say, don't worry if you don't get pledges flooding in during the first few hours. And don't worry about a mid-run dip in pledges. Apparently it's really common for most of the campaign to be a slow lul and then suddenly a flood in the last few days/hours. We were aiming for 10k in a month, got halfway in 5 days, and then the rest was a slow, agonising plod. We got there in the end with 2.5k extra but most of that was 3k in the last 2 days.
So my kickstarter advice is don't fear the lul, but that doesn't mean you should ever stop plugging it.

The order of things.
Like, want order are things going to be done in, is the art first? Or the music? Or will they be done at the same time?

As a programmer, what I'm expected to do, when I'm expected to do it, and will you give me the bloody work or am I going to be blamed if you don't f***ing give it to me.

trooper6 wrote:What is #renpy? Is that a twitter hashtag or something else?

TrickWithAKnife wrote:The Ren'Py IRC channel.

And just since it's timely, I'll point out that #renpy turned 6 years old today.

I'm still actually on hiatus here, but I want to vomit love on everyone who has contributed to this thread! This is really the sort of thread I've always needed but never knew I actually needed it. Kudos to Trick for starting it.

KomiTsuku wrote:There's a 0.0000000000001% chance that your first VN is good. Don't give up.

^ !!

With a year of dev experience (??) under my belt, I still consider myself a newbie as there's still so much for me to learn. I don't have as much to share as other more experienced devs, but I can share my feelings about my first game, The Dolls' Stories. Dolls was not a game I made for other people, it was a game I made for myself so I could test out Ren'py and get feedback, among other reasons. I did think that people might like it, but I'll be honest and say that I didn't give it my best shot because of my inexperience. OTL One year later it is still the game that defines my VN circle; and while the game I'm currently working on is leagues better in terms of assets, plot and planning, I slightly doubt that it will be as memorable as Dolls was. I really regretted not putting in more effort into polishing art and other assets. I regretted thinking of Dolls as a first game to be churned out, just so I can get over that 'first game' phase!

KomiTsuku wrote:Have a plan. Follow that plan.

Do you have a plan yet? Hurry up on that.

Have I mentioned having a plan yet? Know what assets you need from the start, who is going to be doing what, how long you need, and then stick to the bloody plan!

Again, this -- there's no such thing as too much planning at all. I started by listing out ALL the assets I needed for Lemon (excluding word count, that one's harder to estimate), I got placeholder music and worked out the assets right down to voices. (I skipped sound because that was somehow hard to guess as well.) I got an organiser, set a deadline, and divided asset creation across the time taken. It's the third week of Lemon development and I'm happy to say that our team has more or less been juggling deadlines well! Above all, it's a good way to keep you focused and to track your pace of work.

I've also got something like a business plan at the moment, but I'm not very good with finances so I don't feel confident talking about it. Perhaps the more experienced members of the forum has something to say about budgeting?

Finally, I echo Obscura that support from devs and friends alike has been instrumental in keeping me going. From my experience programmers tend to hang out in #Renpy, and artists and writers are on Twitter and on Skype. (I'm so done with Skype because it keeps crashing on me though.) Veteran devs share a lot of useful resources on Twitter and while looking at them can be addictive be careful that they don't detract you from your schedule at all!

On that note I should crawl back to writing sobs

PyTom wrote:And just since it's timely, I'll point out that #renpy turned 6 years old today.

Happy 6th, #Renpy channel!

I wish I'd known that concision, in addition to clarity, is important in writing documentation. Every little thing needn't be explained as a lot can be inferred or researched elsewhere. Documentation is rarely interesting to read, so where possible it's important to keep it to a minimum or no one will ever read it. Thorough documentation is important for large teams who have many members performing the same duties. A team of 10 artists might require a style guide they can reference to ensure assets come out looking similar, for example, but can be wasteful when the team is smaller.

I try to keep my paragraphs 3-5 lines. If they get longer than that, I begin to look for irrelevant parts which could be omitted without changing the meaning / causing confusion, first person commentary, explanations stating why (rather than what), or pleonasm. Of those, the whys tend to be the most common offenders. Documentation is a reference for how something works -- whys should really only be listed in cases where someone might be confused by the what without the why.