RenPY VNs for Win 8 App Store

[jack_norton]

So I decided to try Win8. It's only the preview, but if they don't change it (and I don't think they will) is annoying but definitely nothing so bad as what I'm reading around the net.
You can still open explorer, browse a website (like the awesome www.winterwolves.com! ) and download a game. Just takes a bit more clicks to run the installer but after that it works. If you codesign the installer, it will automatically switch to desktop mode and behave like Win7.
I am almost tempted to say that all this negativity on Win8 is really exaggerated at this point...!

[Shiz]

I wouldn't recommend trying the preview especially when the full version is already released on MSDN(AA) and is shaping up for a retail release soon.

That's always been the problem with Windows computers, for me. You never "own" a windows, your are merely begrudgingly allowed to use it.

Welcome to software licensing in general.


To delve into some App Store requirements:

3.1 You must use only the Windows Runtime APIs to implement the features of your Windows Store app
We describe these APIs in the Windows Store apps API reference. Your app may only depend on software listed in the Windows Store.

If this means what I think it does, you can only use the Win32 API and some other stuff provided by Windows. This would probably kill it already as Ren'Py uses a multitude of libraries like SDL and freetype, which in turn use OpenGL for instance -- not something I'd see them allowing given above policy.

3.2 Your app must not stop responding, end unexpectedly, or contain programming errors.

Quite an unrealistic expectation, expecting something to be entirely bug-free.

3.5 Your app must fully support touch input, and fully support keyboard and mouse input
Your app must provide visual feedback when users touch interactive elements.

This alone would require a large rewrite of both Ren'Py and most games' UI systems.

5.1 Your app must not contain adult content, and metadata must be appropriate for everyone
Apps with a rating over PEGI 16, ESRB MATURE, or that contain content that would warrant such a rating, are not allowed. Metadata and other content you submit to accompany your app may contain only content that would merit a rating of PEGI 12, ESRB EVERYONE, or Windows Store 12+, or lower.

Say good-bye to H-scenes.

In short, I wouldn't expect it anytime soon, unless PyTom finds a way around requirement 3.1, is willing to implement touch support, and you're prepared to deal with requirements 3.2 and 5.1.

[jack_norton]

Well hentai / porn games are already off limits for many appstores. Think about the poor iOS owners that can't enjoy a good sexy story! that is a good reason alone to get an Android device instead
(half joking , but not even too much...)

[Shiz]

The H-scene restriction is probably the least of your worries.

[AxemRed]

3.1 You must use only the Windows Runtime APIs to implement the features of your Windows Store app
We describe these APIs in the Windows Store apps API reference. Your app may only depend on software listed in the Windows Store.

If this means what I think it does, you can only use the Win32 API and some other stuff provided by Windows. This would probably kill it already as Ren'Py uses a multitude of libraries like SDL and freetype, which in turn use OpenGL for instance -- not something I'd see them allowing given above policy.

http://en.wikipedia.org/wiki/Windows_Runtime is not Win32. It's a terrible name, so I can understand the confusion. You can still bundle any number of libraries into your app, Android/iOS style.

3.2 Your app must not stop responding, end unexpectedly, or contain programming errors.

Quite an unrealistic expectation, expecting something to be entirely bug-free.

Just there so they can reject/remove buggy apps.

[Shiz]

3.1 You must use only the Windows Runtime APIs to implement the features of your Windows Store app
We describe these APIs in the Windows Store apps API reference. Your app may only depend on software listed in the Windows Store.

If this means what I think it does, you can only use the Win32 API and some other stuff provided by Windows. This would probably kill it already as Ren'Py uses a multitude of libraries like SDL and freetype, which in turn use OpenGL for instance -- not something I'd see them allowing given above policy.

http://en.wikipedia.org/wiki/Windows_Runtime is not Win32. It's a terrible name, so I can understand the confusion. You can still bundle any number of libraries into your app, Android/iOS style.

'Windows Runtime' is a pretty generic term, hence why I said 'and other stuff provided by Windows'. It seems to me your application still has to mainly use WinRT, thus requires porting native code to C++/WRL instead of whatever Windows API it used before. Not exactly an easy feat. Judging from some searches on Google, it seems manually linking your application to native Win32 libraries will cause it to fail validation.

3.2 Your app must not stop responding, end unexpectedly, or contain programming errors.

Quite an unrealistic expectation, expecting something to be entirely bug-free.

Just there so they can reject/remove buggy apps.

Sure, but it's quite a blanket requirement.

[PyTom]

If this means what I think it does, you can only use the Win32 API and some other stuff provided by Windows. This would probably kill it already as Ren'Py uses a multitude of libraries like SDL and freetype, which in turn use OpenGL for instance -- not something I'd see them allowing given above policy.

My impression is that this means that we must ship SDL and freetype along with the application, rather than requiring a separate download. Those libraries - especially SDL - would need to be updated to support WinRT. In general, a prerequisite for a port of Ren'Py to a new platform is SDL working for that platform.

A bit issue that will bite us is LGPL compliance. To comply with the LGPL, the user needs to be able to swap out an LGPL library for a new version. It isn't clear how this will work in the face of code-signing.

3.5 Your app must fully support touch input, and fully support keyboard and mouse input
Your app must provide visual feedback when users touch interactive elements.

This alone would require a large rewrite of both Ren'Py and most games' UI systems.

I'm not sure of how much of a rewrite this would require, in practice - most elements in Ren'Py highlight when touched.

[Shiz]

If this means what I think it does, you can only use the Win32 API and some other stuff provided by Windows. This would probably kill it already as Ren'Py uses a multitude of libraries like SDL and freetype, which in turn use OpenGL for instance -- not something I'd see them allowing given above policy.

My impression is that this means that we must ship SDL and freetype along with the application, rather than requiring a separate download. Those libraries - especially SDL - would need to be updated to support WinRT. In general, a prerequisite for a port of Ren'Py to a new platform is SDL working for that platform.

Yes, this was the main point I was making in my second post. This would probably be the biggest pain.

3.5 Your app must fully support touch input, and fully support keyboard and mouse input
Your app must provide visual feedback when users touch interactive elements.

This alone would require a large rewrite of both Ren'Py and most games' UI systems.

I'm not sure of how much of a rewrite this would require, in practice - most elements in Ren'Py highlight when touched.

Sure, but there are two issues here at hand:
1) How does Windows 8 handle touch? Transparent mouse-like? Seperate APIs or callbacks?
2) You can't just copy a mouse UI to a touch UI and expect it to work properly -- a seperate touch UI would be required.
Perhaps a rewrite was a bit of an overstatement, but that alone is still not easy.

[jack_norton]

Ren'Py on Android (touch interface) already works fine, the only thing not really supported are swipe gesture, but buttons, scrollbars, etc works fine (if I understood what you mean).

[Shiz]

I'd say gestures are relatively important for touch-based interfaces. Also, I imagine that also didn't come falling out of the sky.