Lemma Soft Forums

Posted: **Tue Jun 14, 2005 12:27 pm**

mikey wrote: I think you actually should finish your script first. There should be a very good reason to wait for BGs - is there? I would say use placeholders and get a wireframe version working in the meantime. Then, when event CGs are done you can fine-tune your script to better relate to the picture, but if you have more or less an idea about the CGs (you have), that's not going to be a monstrous task at all.

Let me second and elaborate on this.

MMZ>> In the script fragment you proposed, you use 8 cgs (not counting backgrounds) for a relatively small amount of script. In at least one case, two cgs are shown without any text between them.

I think that this is, to some extent, a misunderstanding of how visual novels convey information to the user. I'd say over 90% of the actual content of a VN is text, and the visuals serve to make the experience more concrete, and to draw the user in.

So, you probably want to write the story as much in descriptive text as possible, and then worry about adding in images and so on. If need be, a game that is textually complete can stand alone without any images (or with few images), while a game without descriptive enough text is probably doomed. Even in many possible commerical games, much action is depicted without being drawn... So it might be possible to visit a fortune-teller without actually needing a fortune-teller's booth.

Minimizing the number of drawings done also has a number of practical benefits. In general, none of your team members is as excited about the game as you are. (At least, this is what I understand is the experience of people who work as part of a team.) So by putting more of the burden onto yourself, and less on them, you maximize your chance of actually finishing.

Posted: **Tue Jun 14, 2005 12:37 pm**

PyTom wrote:MMZ>> In the script fragment you proposed, you use 8 cgs (not counting backgrounds) for a relatively small amount of script. In at least one case, two cgs are shown without any text between them.

True, there should be a very good reason for this, such as if this were the equivalent of an "intro" to get the player's attention. Then, the game can easily go on without a large number of event CGs.

Posted: **Tue Jun 14, 2005 12:52 pm**

Megaman Z wrote:[[not all choises are noted in the above sample. that's too long to go without a branch, IMO]

Hm... I counted 32 lines of text shown to the user. That's not that much... maybe a minute or two of gameplay. So that's not really all that long to go without a branch.

To put it in perspective, MW is around 1000 lines long, and has 5 menus.

Posted: **Tue Jun 14, 2005 1:06 pm**

Lets see now... I am actually very exited for this game because I would like to play a ren'ai game that I haven't already played 5+ times. ^.^;

And about the cgs (if you are referring cg as computer graphic), he should not have to worry about how many or how little the game will use because once I get the basic character structure all I have to do is add in different emotions and that should not be a too much of a problem or trouble.

I also think their should not be more then 1 choice in the script above XD.

Also demos = evil, just makes you more or less exited about a game that you still have to wait another 4 months to play >.<

sorry I haven't been posting much, just decided to browse around for a tad
~Chas

Posted: **Tue Jun 14, 2005 6:02 pm**

By CGs, we, (or at least I... ^_^;) mean the CG scenes that tend to take up an entire screen and is unique to the game. Generaly CG is just Computer Graphic, but in ren'ai games the term seems to be more specific.

But correct me if I'm wrong please.

Posted: **Wed Jun 15, 2005 3:26 am**

I thought it was short for Computer Generated images. And I tend to try to keep things clear by saying "character image" = character image, "background" = background image in front of which standard character images will appear, "event CG" = one picture with both character(s) and background on, and usually the only time the narrator appears on screen.

I also would encourage continuing with the script even while waiting for images, as long as you've got people who'll draw you the images eventually.

Posted: **Wed Jun 15, 2005 9:52 am**

I see, I will try to remember that. Thanks for the information. And more script is nice, It will also give me a better idea of what characters should look like =D

Posted: **Wed Jun 15, 2005 10:24 am**

I'd be wary of the impulse "must have branches every minute". (This isn't aimed at MMZ specifically, just a general comment) I love giving choices to the player too, but it makes it incredibly hard to get something to a state of completion. The amount of text just multiplies and multiplies. As do the required graphics, which puts a huge strain on the artists. I'd suggest getting one route through the script finished - from beginning to end - before you add too much of the side branches. Because these things just have a habit of expanding out of control, as we've seen too many times...

For similar reasons, I won't join in the guessing game about the innovative features just yet. There are all sorts of cool things that can be done as variations on the format, but there's no point getting excited about them if they never see the light of day. It's great that you got the preliminary version of TOZ finished: but I may wait till it's actually on the verge of being released before I start getting hyped up about it.

Posted: **Wed Jun 15, 2005 12:34 pm**

chronoluminaire wrote:It's great that you got the preliminary version of TOZ finished: but I may wait till it's actually on the verge of being released before I start getting hyped up about it.

I'll generalize this idea a bit - it's one of the reasons you should really time an announcement - longtime in-dev projects will inevitably lose spark even if they are brand new. The name won't sound new, you already know character backgrounds... Offer screenshots or synopses and you have another spoiling effect. It just won't feel so fresh anymore if people are let in on every aspect of the development process. It makes sense to keep a few things under wraps.

Posted: **Tue Jun 21, 2005 8:46 pm**

OH MY GOD!!!! I cant believe i am going to say this but...can you give us a quick update...QUICK...thx

Posted: **Thu Jun 23, 2005 8:40 pm**

here's the status... Chuck and I are still working the fine details on the presentation of Ch. 0 (this could cause a big increase in size. use your head to figure out why... I know at least five of you can guess why), and I'm actively figuring out the small details on Ch. 1 (exactly how much to tell there), as well as figuring out if I'm going to do [some of the] music for the game.

I'll update the siggy when Ch. 1's coding is almost complete (non-essential files not present).

Posted: **Tue Jul 12, 2005 7:37 pm**

okay, I'm back in my usual home, so I can start work on this again... I'm gonna catch up on Ren'Py first (again) before scriptwork is started.

damage report: there wasn't a single thing moved from the time we evac'ed to the time we got back. even the five piece cube on my desk was still intact. (it's composed of five pieces that, when put together correctly, form a cube)

the only appearant damage was minimal, and we were arguing over what to do with that tree anyway.

Posted: **Wed Jul 20, 2005 6:26 pm**

status report:

title music: ~75-90% done (regardless of if I decide to use what I have now, I have to convert it to a supported format. BMS files aren't usable with most players to begin with...)

Ch. 0: a little bit of progress. this one is mainly on chuck, though, so we may have more than what he's telling me... which isn't bad, it just means we're slightly outta sync... don't expect this chapter in a demo release.

Ch. 1: still working on the (written) scripts and juggling a couple ideas for open-endedness... (is that even a word?)

other progress: none, really. I know we're being a little bit slow, but once we really get started...

PyTom, can you see if there's a python function to generate a seed? I'm probably going to want one to bypass the "rollback-compatible" random function in renpy (which is going to be used a lot...)

Posted: **Wed Jul 20, 2005 6:37 pm**

Megaman Z wrote: PyTom, can you see if there's a python function to generate a seed? I'm probably going to want one to bypass the "rollback-compatible" random function in renpy (which is going to be used a lot...)

What do you mean by this? Do ou want a random function that does not participate in rollback, such that you always get a new random value whenever it is called, even if it is called again in a rollback?

If so, you can get it by doing the following:

Code: Select all

init:
    $ import random

choice = random.choice(("duck", "cover"))

Posted: **Thu Jul 21, 2005 8:40 am**

PyTom wrote:
Megaman Z wrote: PyTom, can you see if there's a python function to generate a seed? I'm probably going to want one to bypass the "rollback-compatible" random function in renpy (which is going to be used a lot...)
What do you mean by this? Do you want a random function that does not participate in rollback, such that you always get a new random value whenever it is called, even if it is called again in a rollback?

If so, you can get it by doing the following:
Code: Select all
init:
    $ import random

choice = random.choice(("duck", "cover"))

exactly what I wanted. (I figured other people might want it as well [for testing and what-not], so that's why I didn't put it in a PM)

Lemma Soft Forums

"[mis]tales of ZETA" series official thread