Lemma Soft Forums

Well, unless ads on Android give much more revenues than the standard Flash eCPM, I doubt with a VN you can earn more than $100 lifetime using ads I'm not really a great fan of the freemium model so I'm a bit biased, but exactly because VN is a small niche you have far more chance to make money with the demo/full paid than with ads.

Anyway probably this is a bit offtopic

Yeah probably a bit off topic. I'd say try it before deciding though. Certainly each platform is different, mobile and PC monetization strategies are quite different

Oh, and a question, back to Android needs.

Is there a way to support the various screen aspect ratios?
Essentially I think you'd want two, the key one being widescreen (16:9) and the other 'normal' 4:3. Filling the sides or top/bottom w/black bars isn't bad, but if the whole screen could be used on all devices that would certainly be preferable.
It looked like the screen variants might help to accomplish this, is that the intent?

Variable aspect ratio is in the gameplan, but probably not before 6.15.

PyTom wrote:

Spiky Caterpillar wrote:Also, while I'm not a cryptographer, last I looked, it appeared that vanilla RSA signatures may have been broken a few years ago; while there is a padded RSA approach that's supposed to get around this, the padded one was patented at the time.

I don't believe these attacks are relevant to the way Ren'Py uses RSA. There's an attack that uses the chinese remainder theorem to recover plain texts, but since we're just signing, this doesn't apply. The exponent for the keys we use is also in the good range.

There are some unlikely attacks that padding might prevent. It would be pretty easy to fake a signature for a file with md5s of 00000000000000000000000000000001 or 00000000000000000000000000000000 - but I don't think there's an attack against md5 that allows this. I'm also a little scared by crypto patents on padding, I don't know if they've expired yet.

I'd thought that attacks on encryption could be transformed into attacks on signing - but crypto remains uncomfortably opaque to me.

I suspect they're still in force; Magical Diary uses both unpadded RSA and DSA and rejects the catalog if either signature fails (so at least I hopefully haven't made it worse.). Magical Diary's updater also takes out all the text-file related automagic conversions, on the grounds that it's a lot more likely that I'll intentionally create a file where LF/CRLF differences matter than that I'll intentionally upload using a protocol that converts line endings in transit.

It's practical to create files with colliding MD5sums - see http://th.informatik.uni-mannheim.de/Pe ... ollisions/ . I'm not sure if that can be extended to get a specific target MD5sum, but it does make me nervous.

PyTom wrote:The strategy I'm considering for the next-gen updater will be:

1) Create a tar archive out of the non-generated files on disk - pretty much everything by .pyc and .pyo files.
2) Use zsync to update that file based on the information stored on the server.
3) Decompress the tar archive, putting the files in the right places.

You'll likely also want to add in automatic regeneration of generated files, to avoid UAC-related weirdness on Vista/Seven.

zsync sounds like it may well wind up being useful to me as well - I've been leaving all the new files unarchived to avoid patches triggering a redownload of my titanic .rpa. (Which isn't really a problem at the moment, as I'm half-hoping to encourage fanmods, but.)

cyrus_zuo wrote:The issue is for developers that VNs are something difficult to make money on selling. So a paid version or paid assets are likely only to appeal to a very small group.

They aren't *that* difficult to sell IMO, but yes, developers are a small group. And a picky group - if five other Lemmasoft users have bought a given asset pack, I probably don't want to use the same asset pack for fear of looking too much like the rest.

What I would do if I wanted to monetize Ren'Py more effectively is to ignore the *developer* market and go straight to the end users. Most of the games on http://games.renpy.org/category/commercial have affiliate programs, and the commercial game userbase is much broader than the developer userbase.

cyrus_zuo wrote:So ads allow anyone to casually earn some income off of a free game on Android, w/o having to sell it directly. That seems like something that would appeal to a larger group of RenPy users than the other options discussed so far.

It's a big mistake to assume that ads are something you can just plonk in and forget about while the money trickles into your bank accounts. There's a large inherent conflict of short-term interest between users and advertisers: malware droppers, fraudsters, and just plain annoying advertisers often PAY BETTER than legitimate businesses with inoffensive advertisements do. It's not in the adspace vendor's short-term interest to pay an employee to chase away customers, which means it's likely to wind up being YOUR job as a game author to make sure that your advertisers aren't misbehaving.

I'm now considering breaking this release in half, with the new launcher being 6.14, and speed improvements (especially to screens) being part 6.15. The idea will be to get the first half out sooner.

Another weekend spent working on 6.14. Now that crunch time at work is over for a while, I have more time to spend on Ren'Py, and I'm spending it on the launcher.

Just because I'm working on the launcher, it doesn't mean I'm leaving other parts of Ren'Py alone. For example, I noticed that I was repeating a common viewport scrolling pattern, similar to the following:
That's a lot of boilerplate, and a lot of indentation. So today, I added two new features:

- A block can now have multiple has statements.
- A viewport now takes a scrollbars parameter. If given, it wraps the viewport in a side, and adds vertical, horizontal, or both scrollbars.

So now the code above can be written as:
The new launcher is actually my first big screens-based project, outside the default set of screens. Getting to write a new set of screens will help me improve the design of screen language.

This launcher rewrite is sounding pretty cool. Good luck with it and I look forward to seeing it when all is said and done.

Will the visual improvements include a precision drawing fix in this next update? Because I would gladly fund work on that.

Precision drawing fix?

Basically when the display resolution isn't identical to the 'screen size' settings in the config tile-based maps display with some of the tiles slightly out of position, so you have pixel-wide gaps between them or they are overlapping. That is what I was referring to.

PyTom wrote:Precision drawing fix?

Given that I recently had a PM conversation with Friendbot on this subject, I expect he's probably referring to the one I told you about a year ago, just after NaNo 2011:

Here's an example screenshot of the same point in Tristan and Iseult first in windowed mode at the game's native size (enlarged in Photoshop to match for comparison) and then in fullscreen.

It almost looks like "Tearing" from the image.

I would REALLY like to see this fixed in the next release as my new VN is going to rely heavily on tiled maps.

I'm really looking forward the Translation scan thing, this would be so helpful, really. Good luck.

Friendbot2000 wrote:I would REALLY like to see this fixed in the next release as my new VN is going to rely heavily on tiled maps.

I wouldn't count on it. At the very least, to work on this I need a demo that exhibits it reliably on the first screen.