Novelty alpha released!

[Chibi Kami]

You rule, Sin!

I may elaborate after I've tried it.

[N0UGHTS]

Dammit, your avatar gave me a nosebleed. And I thought I was the only one who liked... PJ sandiwches XD

Just started. I'm not used to using WYSIWYG editors and stuff, so I may actually be more clueless about how to make my game work with Novelty than with Ren'Py. XD I am so useless... Even though I still don't have the hang of it yet, it's still fun to use.

No buggers yet. :p

[DaFool]

Every time I try to launch the program I get a 'This application has failed to start because the application configuration is wrong. Reinstalling the application may fix this problem.' message, no matter which executable I use. Any ideas?

Try downloading and running this:
http://www.visualnovelty.com/files/vcredist_x86.exe
(Visual studio c++ 2005 redistributable)

If that doesn't work, download this and extract the files to your novelty folder:
http://www.visualnovelty.com/files/msvc80.zip

Still doesn't work with me (Windows XP), so it's a shame because I would have loved this program!

Opengl / DirectX / 3D programs are like a hit or miss on my platform on whether they will work at all, but it looks like I'm going to get a new computer soon...

[Sin]

DaFool: Do you know what kind of graphic card you have? Maybe it only has partial support for DirectX/OpenGL.

Just started. I'm not used to using WYSIWYG editors and stuff, so I may actually be more clueless about how to make my game work with Novelty than with Ren'Py. XD I am so useless... Even though I still don't have the hang of it yet, it's still fun to use.

I was expecting this. When I was designing Novelty I never looked at other engines like Ren'py. In fact I've never even used Ren'py. I've downloaded it and run the demo but most of what I know about Ren'py comes from this forum.

Making yet another scripting engine would have been much easier but I didn't want to do that. Making a WYSIWYG-editor birthed its own set of problems and I had to come up with my own solutions for those. Coincidentally Novelty ended up being different to Ren'py in every way. We both employ entirely different design paradigms.

I totally expect that a lot of people will try Novelty, go "oh that's neat" and then go straight back to Ren'py, but that's okay. It's only natural to stick with what you know. At least until Novelty has had some time to mature.

[tigerrenko]

Novelty reminds me of actionscript and Flash, but then again I know very little about it...

TR

[Jake]

Novelty reminds me of actionscript and Flash, but then again I know very little about it...

It seemed to me a little more hand-holding than that (which to my eye, for this kind of thing, is a good thing) - but I did find it hard to get into. I think it's mostly just getting used to the way it works, but I worry that there were a couple of quirks I had trouble getting around that are likely to confuse people just as much as some of the things Ren'Py gives people trouble with.

I suspect many of them could be worked around just by having a slightly-more-complete demo project or templates and a couple of extra helper features (like the text-entry one discussed before). For example, I tried just jumping in without reading any of the documentation, since if it's as intuitive as some people have said I shouldn't need to, right? I had trouble getting dialogue to appear, and eventually resorted to reading up on it; if there was a 'create new template project' as well as 'create new totally blank project' option, the template might have the text-box set up already on the grounds that most people are going to want it there most of the time. Then templates could be set up for NVL, ADV styles, and so on...

[Sin]

Usability is a tricky thing. While you can argue that jumping into a new program without reading any documentation is hard for almost any program with enough complexity, I agree that the interface should be as self-explanatory as possible. In the next version I'm doing a few things to make it more so.

First of all I'm adding hint-boxes that will guide you and let you know when you might be doing something wrong.

Clicking the bubble will open up a help file (html) with further details on the issue and how to solve it.

Second, I'm changing the context-menu for text objects so the dialogue setup becomes slightly less obfuscated.


Lastly I'm updating the documentation to be easier to read and understand.

[Jake]

While you can argue that jumping into a new program without reading any documentation is hard for almost any program with enough complexity

I'll agree that usability is a tricky thing, but I don't agree with this - it's possible to make reasonably-complex tools relatively intuitive. I mean - think when the last time was that you had to look at the manual for a graphics app, for example. A lot of that, admittedly, is shared metaphors and paradigms which have been adopted by so many graphics apps that it's easy to transfer knowledge from one to another, but... to be honest, I don't think I've ever had to read the manual or ask people for help for the basic painting operations in any tool from MS Paint upward.

(Actually, one of the first tools I used for digital drawing was a DTP package called 'First Publisher', but the assertion remains... )



Arguably Powerpoint does everything you would want to do in a vanilla 'kinetic' VN; I've had no trouble using Powerpoint for years without ever looking at the help, it's all intuitive enough. I wouldn't suggest that Novelty has to make everything obvious to the new user, but I think that the vanilla-KN scenario should ideally be the absolute minimum a normal user can manage on their own without having to read documentation.

Lastly I'm updating the documentation to be easier to read and understand.

Just bear in mind that the documentation is typically the last place that gets consulted, usually the user gets around to reading the manual sometime after posting questions on the tool's web forum and/or emailling the author.

[Sin]

The fact that an interface seems alien is a short-term issue and that's not something I'm going to waste any time correcting.
However, if there really are unnecessarily complicated things in the interface then of course it's in my interest to make it easier, but you still need to make the distinction.

Help files are very useful. Just because people are uneager to read them doesn't mean I shouldn't write them. Besides written tutorials I've also put up video tutorials on the website to help people get over the (relatively small) learning curve.

The purpose of the new hint-system is to say "Hey! I see you're doing something that might not work like you intended. If you want, I can show you what you need to do". Even if they end up directing you to a help file that still is a very smooth user experience.

But I'm guessing you're saying I should do a demo that is more like the Ren'py demo and yeah, I will probably make one in the future.

[mikann]

A demo like the one included with renpy would be okay.. but only if you show how to do it in-game. That's one of the gripes I have with Renpy's demo.. you have to open a separate window to see how it's done, and sometimes it's all scattered around (a little bit at the top of the documet.. a little bit in the middle of the document.. it's confusing to copy).

Show how to do something, and show how it works.

[monele]

Show how to do something, and show how it works.

Do we need more screencasts?

[Jake]

However, if there really are unnecessarily complicated things in the interface then of course it's in my interest to make it easier, but you still need to make the distinction.

The fact that the interface is 'alien' isn't in itself a problem, because any new UI for this kind of thing is going to be different to something I've seen before. It just means that I don't have any prior experience - and neither will anyone else - so the UI needs to take more care than usual to walk me through the first steps. The really obvious example of this is having to add objects to the scene and then bind them to dialogue just to display anything - it's currently so far from intuitive that I would expect it to needlessly frustrate and put off some significant proportion of users. Given that it's a VN engine, and showing dialogue is fundamental to the operation of a typical VN, it could be improved.

On the 'random usability things' front, as it goes, a few suggestions:

• One thing that caught me out, although obviously it becomes apparent how they work once you start using them - in the majority of programs, corner resize handles operate using the opposite corner as a fixed point, not some arbitrary anchor. Those that don't tend to use the centre point of the image instead. It might be an idea to consider defaulting the anchor to the centre of the texture rather than the top-left, since this is going to take the least getting used to for people who have used other apps with resize handles.
• I forget, did you say you were going to allow zooming with the scroll wheel? It'd be pretty useful, to my mind.
• Snapping objects when dragging to the edges of the 'screen', similarly, would be pretty nice, at least as an option. Maybe even also to the centre of each axis. Especially useful for things like backgrounds...
• Why is there a 'time' parameter to 'show object at' or 'change visibility'? It doesn't seem to actually affect anything...
• Speaking of actions, I'm sure it's probably on your to-do list already, but it would be pretty nice to be able to drag actions or items within scene layers or so on instead of having to use the 'move up' and 'move down' buttons.

Help files are very useful. Just because people are uneager to read them doesn't mean I shouldn't write them.

Oh, sure. I'm just saying, when you're writing them and when you're considering other things to help users get used to the app, bear in mind that most people won't look at them first, or probably even second. The hints certainly look like a good idea to help with this, though.

But I'm guessing you're saying I should do a demo that is more like the Ren'py demo and yeah, I will probably make one in the future.

Well, that would certainly help. But also - particularly with things like the dialogue issue - I'd still suggest game templates to kickstart a user's project.

Again, look at Powerpoint - one of the reasons it's easy to get started using Powerpoint is that when you create a new presentation, it doesn't just give you a single blank slide; it gives you a slide with a title field waiting for input with "Click here and write a title" or something displayed, then a second slide with the general bullet-point text object already applied, with "Click here to start writing" or something showing. And when you add a new slide, it doesn't just give you an empty slide, it gives you - IIRC - an empty copy of the objects you added to your second slide, presuming that that's what all your content slides are going to be like. And it works - people have no trouble getting started writing simple Powerpoint presentations, and people who are used to the way Powerpoint works don't seem to mind; these things are easy to delete, if nothing else, and I suspect there's a "start new blank presentation" option as well.

So, for Novelty, I reckon it's probably worth having "New Novel" create a template (perhaps it could pop up a template selector window, for that matter) which has a text box set up for dialogue, and one for a character name, with an example frame or two behind them. Maybe an example background already in place in a second, lower layer.

(The thing that worries me about the approach that you've taken, basically, is that it's incredibly generic; it seems, for instance, that instead of explicitly selecting a background for a page, we're supposed to add a background object and place it behind everything else. This makes the engine very powerful, but I suspect most users who are looking for an easier, more intuitive alternative to something like Ren'Py would prefer a tool specifically catered to normal-use VNs, in which they just select a background for each page from a dropdown or something. The more flexibility, the harder it is for the obvious normal usage to be easy and straightforward.)





On a totally unrelated note, by the way - I'm sure you've probably noticed yourself and quite possibly fixed it since releasing the alpha, but just in case: all the textures drawn by Novelty, at least in the editor, seem to be pretty blurred. It was most noticable for me on the Tsuina and Kabota characters, but the more I look the more it seems to be the case for everything. It looks exactly like the problem I had in the OpenGL 2D engine I was writing recently, in that logical position unit boundaries weren't lined up exactly with display pixel boundaries, so a single pixel of the display was sampling from more than one texel. I guess this is possibly a result of centring the display area inside the UI frame it's contained within?

[Sin]

On a totally unrelated note, by the way - I'm sure you've probably noticed yourself and quite possibly fixed it since releasing the alpha, but just in case: all the textures drawn by Novelty, at least in the editor, seem to be pretty blurred. It was most noticable for me on the Tsuina and Kabota characters, but the more I look the more it seems to be the case for everything. It looks exactly like the problem I had in the OpenGL 2D engine I was writing recently, in that logical position unit boundaries weren't lined up exactly with display pixel boundaries, so a single pixel of the display was sampling from more than one texel. I guess this is possibly a result of centring the display area inside the UI frame it's contained within?

I'm aware of it. I've checked and triple-checked but all the coordinates are perfectly in line. It could be the linear interpolation of the texture that causes it. You can turn it off by checking the Pixelate-property of an object.

One thing that caught me out, although obviously it becomes apparent how they work once you start using them - in the majority of programs, corner resize handles operate using the opposite corner as a fixed point, not some arbitrary anchor. Those that don't tend to use the centre point of the image instead. It might be an idea to consider defaulting the anchor to the centre of the texture rather than the top-left, since this is going to take the least getting used to for people who have used other apps with resize handles.

Those handles doesn't resize, they scale, so they're dependent on where the origin/pivot point is located. To resize you hold Ctrl and drag the blue handles. The reason for this is because I want to encourage people to scale rather than resize whenever possible.

I forget, did you say you were going to allow zooming with the scroll wheel? It'd be pretty useful, to my mind.

It's already in there. Again, hold Ctrl and scroll the wheel.

Snapping objects when dragging to the edges of the 'screen', similarly, would be pretty nice, at least as an option. Maybe even also to the centre of each axis. Especially useful for things like backgrounds...

Already in there. Hold shift.

Why is there a 'time' parameter to 'show object at' or 'change visibility'? It doesn't seem to actually affect anything...

The time parameter is for running scripts. The script (OnShow/OnHide) is being called for that amount of time, giving you the opportunity to script a fancy fade-effect or transition. I haven't written any documentation on this yet because I've purposely neglected the advanced features. That's one of the things I'm going to add now.

[Jake]

I'm aware of it. I've checked and triple-checked but all the coordinates are perfectly in line.

I'm not familiar with the way DirectX works, I've only coded such things in OpenGL, but - have you tried a 0.5px offset in each direction as well, just in case that's how it does its sampling?

It could be the linear interpolation of the texture that causes it. You can turn it off by checking the Pixelate-property of an object.

Mm... my problem with it personally is that I'd prefer the default behaviour to be to interpolate when I've resized the image away from a 1:1 display size, but to have a true representation of the original image if it is displayed at the asset's original size. Possibly a candidate for a configurable option?



Another usability thing that I forgot about that I remembered when I was checking the Pixellate property - I realise it's not so straightforward to do, but it'd be nice for a texture-based object to not get selected if you click on a transparent part of it. Probably even just ignoring clicks on 0-alpha regions would be enough... but it's irritating to click on one character and have Novelty select the one that's in front of it because she's holding a broom out such that her bounding rectangle happens to overlap the one you wanted to select.

[Sin]

I'd prefer the default behaviour to be to interpolate when I've resized the image away from a 1:1 display size, but to have a true representation of the original image if it is displayed at the asset's original size. Possibly a candidate for a configurable option?

Yeah. As I was writing that response I had the same idea.

I don't think I will do any alpha-picking when selecting objects. Objects can be made up of multiple child objects, including native font objects that I can't easily perform any alpha-testing on.
If you have objects in the scene that are "done" that you're not going to change you can stick them in a separate layer and click the lock icon. A locked layer will be ignored by mouse-clicking and selections.

I built Novelty to be super generic, so that's all by design. It demands more of the user, I know, but not a lot. I believe that in the end it will give more freedom to the user. I've made a few shortcuts for the lazy, like right-clicking an image and selecting Manipulate->Make background. It resizes the image/object to fit the screen, puts it in a separate layer at the bottom of the scene and locks it.