— - that's sort of what I'm doing, I guess I didn't describe it well enough. The first third of the game/story arc will work just fine as it's own game/story. It won't leave off like stopping a movie partway through with huge plot threads hanging - there will be some unanswered questions, but part 2 will be more like a sequel instead.

Update:

Progress continues. There are new abilities, a new enemy, the characters can leave/enter areas, I've implemented the start of the tutorial system, worked on the ui, fixed bugs, etc, and I've begun the level editor.

Some info about how the game is going to be released:

As it takes longer for me to work on something than most people, and honestly, the game is a lot to tackle as one project, I'm going to release the game in stages instead.

Stage 1: prototype/proof of concept

Stage 2: first section of the game

Stage 3: first story arc as its own game

Stage 4: second arc

Stage 5: third arc

Having a prototype will help me to make sure people like it and it's at its best. It has 3 separate individual arcs anyway, and each will be long enough for a complete game (small for an rpg, nowhere near a hundred hours or anything, but enough), so it seems appropriate to make it a 3 part trilogy rather than one big game, as each part will stand alone just fine (I know, I know, I have a problem with being overly ambitious. I don't care ^^).

The battle system is quite playable as it is, but there isn't enough yet to give a proper impression of what playing the game will be like. It's still months away from being ready (it's probably half done), but I'll update again before then when I have something to show.

moxBorealis there's a difference between focusing on the negative and discussing ways to address something's weak points and how to make it better, which I think most, if not all of of us are doing.

I think the node webkit exe export is suitable for making a large game. I say I think because I'm not 100% sure about it as I don't know how big the games released using it so far are, but they look to be at least medium sized (airscape, angvik, our darker purpose, the next Penelope (I think?), super ubie land, courier, game dev tycoon which isn't c2 but still uses node webkit, etc).

In my own tests, I have been able to export a test capx with a ton of graphics and events, and it still worked fine. The only issues I know about are potentially long loading times on some computers and no hardware acceleration on XP/vista which Ashley is currently looking into a way to fix by turning off the gpu blacklist.

robert420 - Thanks for the link, but the problem is actually because of the chrome team deciding to disable software acceleration on all computers running XP and vista.

Problem Description

Node webkit, in export and preview, has software rendering on 32 bit vista.

For some reason it seems to be ignoring the --ignore-gpu-blacklist flag in the package.json and package-preview.json files (the flag was actually missing in the package.json file, adding it didn't help). If I create a shortcut to the NW.exe in the construct 2/exporters/html5/node-webkit/win32 directory and add " --ignore-gpu-blacklist" to the target, run it, then put in the preview address into the address bar, then the framerate is smooth. Adding " --disable-software-rasterizer" to the shortcut instead is ineffective.

Running from a modified shortcut is the only way I've found to get it to work, but that's not a reliable method if the user decides to launch the exe directly. Maybe it's a bug in node webkit itself.

Attach a Capx

Description of Capx

All .capx files are affected, including the space blaster demo game. I'm not sure how to provide a .capx for this because if a computer's CPU is fast enough to run it even in software rendering at 60 fps, then the effect would not be noticeable compared to if it was working properly, so the best recommendation I have is to duplicate the background tiles of space blaster until it starts hitting the frame rate in software mode, then compare with my shortcut method above (this of course is only if you even have access to a vista computer). Maximizing the window also impacts the frame rate more severely.

Steps to Reproduce Bug

• Step 1 - open space blaster on a vista machine.
• Step 2 - preview in node webkit.

Observed Result

Framerate is vastly lower than it should be because of software acceleration.

Expected Result

Hardware acceleration should be on.

Affected Browsers

• only node WebKit (well, chrome too, obviously)

Operating System and Service Pack

Vista 32 bit sp2

Construct 2 Version ID

164.2

Yep, will do.

— - I'm afraid it's not working any better on vista - I'm still getting software rendering with both node WebKit's preview and export.

For some reason it seems to be ignoring the --ignore-gpu-blacklist flag in the package.json and package-preview.json files (the flag was actually missing in the package.json file, adding it didn't help). If I create a shortcut to the NW.exe in the construct 2/exporters/html5/node-webkit/win32 directory and add --ignore-gpu-blacklist to the target, run it, then put in the preview address into the address bar, then the framerate is smooth.

Running from a modified shortcut is the only way I've found to get it to work, but that's not a reliable method if the user decides to launch the exe directly. Maybe it's a bug in node webkit itself.

I generally put them in their own event sheet for that reason. But yeah, it would be nice for variables in a top level group to be global.

Hmm, I'm not sure. I guess I would need a capx to investigate further.

Yeah, else does no picking at all, nor does it remember or invert the picking from the event above it. I don't think you should use any of the else conditions in that screenshot at all. Instead of:

Event 1: X is less than player.x

Event 2: Else

Use:

Event 1: X is less than player.x

Event 2: X is greater or equal to player.x

https://www.scirra.com/tutorials/418/for-each-tutorial