Another thread popped up last week about this and I got a response from him on the GHG Forums

Well if it's controllable via events, then you could add graphical options to enable/disable it.

That way the end user can have control over it, like most big PC games.

The developer can include it along with options to reduce particles and such as well.

I just think the option for it to be there for the dev is important as smooth gameplay is just as important as good gameplay. Lower graphical settings also increases potential userbase.

That and it's not always good to force a device to have a constant full load to process.

Construct 2 may be HTML5 based, but Game Dev Tycoon is a game on steam that's HTML5 based. It uses Node-webkit to be an EXE.

HTML5 game does not automatically equate webgame.

That said, C2 would work fine for a metroidvania.

Game Closure blog of porting Space-Blaster

Seems like the things needed to convert it to Game Closure would be upon-export. Hopefully it wouldn't be too much and I do not know how much information in the SDK there is on Exporters.

But the GC people back in March/April proved it possible. They gave C2 praise and I don't see why they wouldn't make an exporter themselves if given proper documentation, or even assist Scirra if exporter SDK info is protected.

Yeah, one of the things that makes Unity very popular is the ease of access to community content with the Asset Store.

Depends on what you plan on doing really.

Personally I'd say it's better programming to make different enemies different objects, but putting those objects into an ENEMY family. This way it's easier to pick which enemy you need for events, as well as reduce the number of conditions needed to differentiate them.

There already is a Show Grid on the layout view thing, right by the grid size and snap to grid options.

The image editor could use some work, however I do suggest that if you're going to being doing a lot of pixel art, to do it outside of C2 as you get access to many many many features that are not priority at all.

Many modern image editors/pixel art programs have layers and etc. C2's image editor is like MSPaint atm.

> I told Ludei to maintain the C2 CocoonJS plugin themselves. There shouldn't be any ambiguity here. They kept making breaking changes to their API, and when I asked, they couldn't even tell me what they'd changed. It didn't seem reasonable for me to try and maintain it under those circumstances - it was a nightmare for me, whereas they know their own API, presumably - and then they asked me to add more features... so I told them to do it themselves!

Forgive me for being so direct but, why dont Scirra make its own exporter?For CocoonJS or for mobile period?

For the former, the post explained why.

For the latter is that they are working on C2 and that if they work on an exported C2's production would cease, in which during the time the wrappers would have improved to the point where their own exporter/wrapper would've been a waste of time since they would only provide minimal feature support due to lack of time.

The main problem Scirra has for tackling it is that they're a 2-3man team, and they just don't have the resources to do that AND make Construct 2. Putting C2 on hold too long is very bad.

What we need is an open source wrapper, essentially Node-Webkit for Android/iOS. That way the project is supported by many people, and either they or Scirra would just have to stay compatible by updating the plugin/exporter. Basically like how they do Node-Webkit for PC.

The human eye can see more than 18fps. Films are made 24fps for smoothness as with the way it projects, that's the point where it starts looking smooth. TVs (NTSC) are 29.9, and people can see the difference between that and 24fps.

Computers are 60hz and most games are 60fps. Many people notice the difference between 30fps and 60fps.

The problem I have with FPS isn't that higher is smoother, is that variable FPS can cause a bad user experience. That being said, it's the developer's responsibility to have specifications on the target hardware and scale the game down accordingly.

HOWEVER, Consoles are framerate limits due to hardware limitations and to ensure smooth operation. They're more concerned with the professional 30/60fps.

Mobile devices are also limited devices that if you can make a game run smoothly at 30fps, but have a hard time meeting 60fps, then there should be an option or a way to limit it.

That doesn't mean to not adjust the graphical load to meet hardware demand, just that framerate limiting is the /last/ step you do.

IMO while there is justification for a FPS limiter, there's no real reason to do so while the market and standards are changing so fast your game might run at 30fps today, but 60fps next week.

Once the field settles, and limitations are being met left and right, then maybe there would be a real reason. (Although a global delta-time multiplier to enforce framerate shouldn't be too hard to implement)

Edit: But this is mostly PC/Browser games. Mobile exports are usually 3rd party so it would be an option for CocoonJS or Phonegap to introduce FR limits to set for apps.

Try making sure the tiledbg texture is a power of 2

Also try to see if the resize mode of "Letterbox Integer Scale" removes them as well if previous advise does not solve issue.

Ashley

Patrick responded on the GHG forums about their implementation

Currently they have limited support (Cloud/Acheivements), but aim to hopefully open source the implementation later this year after cleaning up the code.

So thankfully they're still going to release their implimentation, and should be something to watch or even help expand once Open Source.

You should check out how the Kirby series progressed.

Specifically:

Kirby's Dreamland -> Kirby's Adventure - > Kirby Super Star

Simple fun platformers, with feature improvement with each game. (I did not play KD2 so I cannot say anything on that)

Kirby's Adventure is a fantastic NES game that pushes the system to it's limit (one of the later NES games as it was released in 1992)