Questions about ONscripter...

[papillon]

You mean harder as in harder to find or as in more expensive?

Both. Like I said, there are a lot of sites - sounddogs.com is one - where you can go and easily search for music and sound effects, get tons of options, find something that works for you, buy it and plug it right into your game.

With art, you're not likely to find something that's already made that works for you, because your needs are a lot more specific. (Well, you might be able to find some ready-made 3d graphics packs that you could assemble to use for backgrounds. And there's clipart.com but they rarely have anything that would be suitable for a bgame.) So you'll have to find an artist, get them to agree to it, pay them lots and lots of money, nag them to get the job actually finished, WAIT for them to get te job actually finished...

[Counter Arts]

Wow... I'm working on ONScripter for now and it's powerful as people have been saying. It's like assembly language code.

Funny thing... I've actually studied a bit on how high-level code gets translated to assembly language code. I took a quick peek at some game script and thought, "Wow, they made their own language to compile into this. "

Makes sense really, altrough I might be sounding "Captain Obvious" right now.

So I've been thinking if I could create my own language to do the same. It totally loses the power of ONScripter, however I think it would be great. It would be a good thing to put on a resume too.

Uber-Easy Romance Code

(UERCode)

Code: Select all

Define
  
  tWindow:
    fill = BLUE
    x = 32
    y = 3

  character AYU:
    name = "Ayu"

    stats:
      love = 2
      pwnageAblity = 1000
    
    expression:
      SAD = "AyuSad.png"
      HAPPY = "AyuHappy.png"
  ...

  character CIEL:
    name = "CIEL"
    
    stats:
      love = 19
      pwnageAblity = 1000

    expressions:
      SAD = "CeilSad.png"
      HAPPY = "CeilHappy.png"
      INSANE = "CeilScary.png"

  ...

  area park:
     normal = "ParkNorm.jpg"
     night = "ParkNight.jpg"
     burningclimax = "ParkOnFire.jpg"
   
  music happy = "happymusic.mp3"

  music finale = "finale.mp3"

gamestarto

   set effect wipeleft
   
   music happy

   background park normal

   show at left AYU HAPPY

   [AYU]

   << Oh, I love you!

   show at right CIEL INSANE

   quake

   [CIEL]

   << You stole him from me!

   show at left AYU SAD

  [AYU]

  << Oh noes! It's... it's... insane Ciel! Don't you have a Shiki to get back to?

  [<PLAYER>]

  << Oh great... it can't get any worse.

  musicstop

  [["Random stranger"]]
  << Look! It's the metor from FF7 that's coming to hit this park and set everything on fire!


  [["Metor"]]
  << All your base are belong to us!

   music finale

  << You are on the way to destruction.

  [["Earth"]]

  << What you say !!
 
  [["Metor"]]
  << You have no chance to survive make your time.
  
  quake

  set effect fade

  backgroundColour WHITE

  background park burningclimax 

  [PLAYER]

  << I'll shut up now...

the end

Would anyone be interested to code like this?

[PyTom]

Some random comments on Counter Arts's post.

I thought the same thing that you did, that the ONscripter/Nscripter language was the output of some tool. IIRC, someone on one of the translation forums, or perhaps here, corrected me on this, mentioning that they really do expect people to program in Nscripter directly.

In retrospect, the Nscripter language is probably closer to ad-hoc languages like CNC then it is to proper assembly languages. You have a large number of variables, so you won't need to do anything like register assignments, and in general your concepts map 1-to-1 (or at least 1-to-a-few) onto Nscripter commands.

I hope you've looked at Ren'Py, which implements a high-level approach to writing VNs, at least for the actual story-writing part of it. You may be able to get some good ideas.

One thing I found worked is that you want to minimize the number of statements that are found in the language, and to try to avoid conflating things if possible.

In your demo script, you have two kinds of image statements, background and show. It's not clear to me that this is a good idea. What if, for example, you want to show a two-layer background, like the inside and outside of a house.

Likewise, you allow stats on character objects. What if I have a stat that spans two characters? If you allow for global variables, why bother having stats on characters at all?

These are just some of the decisions you'll need to make when designing a VN language. My eventual conclusion was that it's best to define a few simple constructs for common tasks (dialogue, menus, showing and hiding images, etc) and for stuff that the language has to express (control structures), and leave the rest of it to generic constructs that handle function calls and configuration.

Finally, realize that while getting a basic system working is relatively simple, the hard part is making it flexible enough that game-designers can achieve the look they want for their game.

[Counter Arts]

I'm just recovering from exams so I can't really work out the weird problems of UERCode just yet.

I thought the same thing that you did, that the ONscripter/Nscripter language was the output of some tool. IIRC, someone on one of the translation forums, or perhaps here, corrected me on this, mentioning that they really do expect people to program in Nscripter directly.

Yep, I could see that. But I kinda think that AugestSoft did something like that anyways. Either that or they have amazing template to make games with which I can understand.

In retrospect, the Nscripter language is probably closer to ad-hoc languages like CNC then it is to proper assembly languages. You have a large number of variables, so you won't need to do anything like register assignments, and in general your concepts map 1-to-1 (or at least 1-to-a-few) onto Nscripter commands.

Yep... I won't have to do the complex REAL compling. That's what I would like since I don't like to read through the entire script twice unless I had too.

I hope you've looked at Ren'Py, which implements a high-level approach to writing VNs, at least for the actual story-writing part of it. You may be able to get some good ideas.

One thing I found worked is that you want to minimize the number of statements that are found in the language, and to try to avoid conflating things if possible.

I hope you've looked at Ren'Py, which implements a high-level approach to writing VNs, at least for the actual story-writing part of it. You may be able to get some good ideas.

There are somethings I can't implement very easily and withminimum pain that are in Ren'py. Your Menu sets and animations I can't do easily without some work beyond my as-close-as-possible 1-to-1 mapping or really easy implementation.

One thing I found worked is that you want to minimize the number of statements that are found in the language, and to try to avoid conflating things if possible.

Since I'm not planning on doing a lot of hard work on this just yet, I don't plan on making this language much bigger at all except for some choice statement (which somehow slipped my mind). I am the only member in Sakura Maple so far. Guess who just joined IntRenAiMo.

In your demo script, you have two kinds of image statements, background and show. It's not clear to me that this is a good idea. What if, for example, you want to show a two-layer background, like the inside and outside of a house.

I guess I'm being Paintshop/high disk space biased then. I thought of it too. I thought "If they are going to be doing stuff like that, they are going to learn ONScripter. Otherwise I can't see why can't they just make the different variations on seperate images."

I should have picked a better keyword than "show". But I can't think of anything better. This will only map directly to ld usages.

Likewise, you allow stats on character objects. What if I have a stat that spans two characters? If you allow for global variables, why bother having stats on characters at all?

I can map character stats to arrays easy (if ONScripter works like I think it does). I'm guessing that if some one is going to use this language for a stats-based game is probably going to be using simple arithmetic math.

Stuff like love stats being altered from a simple choice like how they probably do it in the Hourglass of Summer or Sakura Wars.

However, if they really want to get more advanced then they can look at the generated script and figure out how it works and modifiy it from there.

I really want to just make this so that non-programmers can use this really fast. Espically the artistic ones who are clumsy with computers that scare easily. (Oh no! It's Qbasic! Run!)

Also, I can kinda see the use of this for great programmers too. It provides a simple and somewhat fast way of just getting a game prototype done. Limitations could spur inspirations as well. I'll think I'll put a feature where you can just insert ONScripter code too.

EDIT: Oh, in case I didn't mention it I'll probably do this in C++.

[gp32]

To confirm once again -- yes, people ARE expected to write in raw NScripter, and there are no high-level UI-based templating tools to make things easier. To address the speculations on August Soft's NScripter-based games -- each game from Binary Pot up to Hanihani was a linear expansion of the same engine -- the NScripter programmer did a good job once, and then simply added features as he went. No high-level tools were used. None were necessary, either; PyTom is right when he points out that NScripter really isn't as close to assembly as you'd think. It *is* quite close to the pseudoassembly that many instructors use to highlight points during programming classes, but that's about it ...

[Counter Arts]

I know I can just figure out how to program ONScripter. I don't think everyone can do it.

If I actually do make this... then the real purpose of something like this is to let people have an easier learning curve with using ONScripter. Eventually they will be look at the ONScripter script and figure out for themselves faster on how to use ONScripter. Then they never use my tool again.