cjbruce Yeah both of the 3D plugins for C2 is pretty good. I understand that scirra don't want to make Construct a 3D editor, but I do keep my hopes up that somewhere down the line they would consider adding some functionality that plugin creators to make use of, to get a better viewport for those plugins

For now I'm going put my efforts aside with the 3D plugins. Technically it works great, with good performance, it's just the editor that doesn't support it fully yet, so it's tedious to work with.

If there is any chance your game might end up being played on living room TVs, eg through androidTV/shield or even console then you might want to consider 1024 576, I found, unless you are specifically aiming for a blatant pixel art look, lower resolutions on big HD TVs just look too pixelated and expose a lack of detail you don't notice on smaller HD screens.

I found 1024 576 was a good compromise. It gives a sort of amiga500 higher res pixelart game look on big TVs.

I was aiming for mobile to start with. All the assets are rendered in high res, so I could release a "HD" version later, for TV's and tablets. I just wanted to optimize the game to be playable on low-mid end phones without running into memory issues.

I wish there was a way to chose what assets to load. Now I have to settle for something that looks okay, on High end phones with big screens, but is playable on low-mid en phones. >_<

Drat. Now you have me worried, as I am getting close to starting the level design process with Q3D. Using block art and a top-down level layout I hadn't anticipated too much of an issue.

What specifically were you seeing that was giving you trouble? Was it doing things like trying to match up Q3D models with their shadows?

Also, I concur that the 640x360 looks a little better.

It's just that i have sooooo many objects of different kinds in different sizes from small pebbles, mushrooms, twigs, flower, to large houses, and trees. Placing all that on the map without any accurate representation of what it would look like until I press preview was my major turn off. If i had the patience I could probably pull it off. If I had a lot less assets and a flat level (instead of height variations as i was doing) it would be a lot easier. If you're game is pretty simple, and most assets are on the same plane, and similar size i guess it's okay. I guess my game is just too complex in terms of the details

That's my only issue... visual representation in the editor.

I just didn't have the patience to place something, preview, tweak position and scale, and test again for thousands of objects..

I havn't done any significant testing, only some small ones for personal curiosity. But when it comes to rendering I didn't find any issues.

If you have a simple test scene running at 160 fps in native, but 60fps in WebGL, it doesn't mean native is double performance, as WebGL is capped at 60fps, so you can't really compare.

Only when you start adding loads of stuff to you can start to compare.

Set a target fps of 30, and start spawning rotating sprites, (like in the C3 example), then you can tell the difference. The one who spawns more sprites is the winner.

The only thing I noticed in C2/C3, is picking and loops that sometimes feels like it's using more CPU or has more overhead than it should have, and would probably be faster in javascript, or native code, but I don't have anything to compare with, so often it seems like behaviours are a lot faster for these kind of things.

Another thing is draw calls.... I'm not sure if this is faster on native or not, but it scales with how many sprites on screen. This will use more CPU the more sprites you have on screen.

As picking/loops and draw calls scales with # of sprites, maybe this the only bottleneck in C2? A badly optimized game, would have less resources for draw calls, so slower rendering?

So my conclusion is that the only thing that could probably be faster in native, is draw calls and loops, but the actual rendering is just about as fast. More sprites & effects in C2, would have more overhead maybe?

I could be wrong but that's just my observations from my own testing, and I havn't done any cross engine testing of this.

Based on the mock ups I'd go with 640

320 ruins the look of your game

Thanks Yeah I think I'll go with that... I think I would save enough memory just by optimizing the assets for 640x360 instead.

Separating trees and other assets to - tree trunks and canopy, i could save a bit of memory as well, and mixing and matching, instead of using several full trees sprites in different variations. Characters and animation I could also separate to smaller parts, to save more memory, but a bit more work.

Oh, that was well hidden!!!

I thought i could just double click the Array object in project bar, to start editing. Maybe I should put that in as a feature request

May 15 update.

Playing around with Q3D, everything seems to be working fine, but been struggling with level editing. I've decided to go back to 2D isometric, as any type of level editing with lots of small props and items placed all over the map at various height and sizes is too tedious to work with, since C2 doesn't support any 3D viewport. All of the benefits of Q3D, doesn't add upp when it comes to editing levels. As I can't get a clear view of what I'm doing, as the visual representation in the editor is lacking.

Hopefully at some point C3 will open up possibilities for plugin developers to make a proper viewport..... so ...

What to do?.

The main reason i tried Q3D was memory issues for mobile, as i wanted a lot of props, characters, animations, and sprites on the map, which was hard to accomplish given that I was aiming to use less than 100Mb memory. Currently my game was using about 50mb, and that's only with 1 character, and maybe a forth of all the sprites I wanted to use. So what's my next option?

* Lowering resultion. Instead of using highly detailed sprites, rendering the game at a resolution of 1280x720, i could save a lot of memory by lowering the sprite resolution. So looking for some feedback here? Should I go for really low pixel art 320x180 or 640x360? Check mockup image below to get an idea.

640x360 would use about a fourth of the memory, so that should be fine.

320x180 would be really pixelled but i would have even more memory budget to play with, for assets, animations, etc etc...

Should I aim for 640 or 320? what do you guys think? what would look better?

I was quickly checking out the full version (available for Game Jam) but noticed some missing features, or what I thought would be available for game jam.

In particular, the new editors (Array, dictionary, text)? Or I just didn't find them?

Covered in this blog post

https://www.scirra.com/blog/192/new-editors-in-construct-3

Any ETA on when those will be available? I was looking forward to play with those, during the jam.

glerikud

It was not a suggestion I was trying to prove a point why full editing capabilities without subscription is not a good idea. From an exploitability/business perspective. If you read the whole post.

Some kind of lockout has to be in place. Otherwise it would be exploited. As a user I rather have the lockout, than have the devs spend all their time on security/exploit issues and losing business, instead of adding new features and updates.

I can live with paying once a year for software that I like. No biggie. The payment model/lockout is the least of my worries.

Are You using different layers with parallax setting?

Are you checking the dotted line in layout editor. That's the window size. What you would see on screen, are you setting that in code? Or do you use some special letterboxing setting?

agree with michael, it would simplify support. Maybe even possible to add a nag screen to, standalone if unsubscribed?

-You are using an outdateted version, click "here" to resubscribe ,and get access to latest updates, and all features.

I still don't get why people are still,driving this agenda. It's like they already set their mind that they wouldn't pay again in a year, but gladly continue to use the softwre, until they feel like it's time to upgrade...

If I was Scirra I wouldn't consider it unless I could make sure the limitations were severe enough.

* Pre subscription customer. Access to limited online 50 event online version.

* Subscription customer. full access. Ability to download standalone version.

* Post subscription customer. Full editing capabilities in Standalone version, but no export options at all. Not even html. Only preview option.

I do see a few major exploit possibilities here:

*Latest standalone version could probably always be found online, somewhere else. Since every subscriber would have access to it. You would probably need an account status check here. If someone using a standalone version later than they should be allowed all access should be blocked, or limited to 50 events.

*Same Standalone version installed on many machines in a team, but only one person need a valid subscription with export option. Big loss in business.

*People could start offering export services to standalone (post subscription) users, who, pretty much has full software but without export.

*People spending months and years to create full games but only pay when they are done, and need to export?

I don't think that a standalone version with full edit capabilities should be a post subscription benefit, unless you can make sure you can severely limit it, and have the proper security measures to not be exploited.

Using a standalone version: you should have to log in to use it... a check if you are entitled to use this release, according to, your latest subscription info, if not you would be limited to 50 events like other free users.

The ammount of work just to accommodate people who clearly don't want to pay more than once, I would rather have the devs spend on new features, for people who don't mind playing. And I don't think that people without an active subscription should be able to work on their 50+ event projects at all.

Don't buy in to it Scirra. Don't spend time and energy to accommodate people who clearly don't have any intention to continue to subscribe after the first year. They want a feature that will allow, them to create full games without paying, and only pay when they need need to export. (Unless they send the c3p to someone with a valid subscription and askmthem to export it)

I just see soo many warning signs here..... Maybe they don't have bad intentions, but the possibilities for exploits just shot through the roof. I would rather have the devs focus on making a good software, and awesome features, than working on security measures and accommodating non subscribers, so, they can work on their stuff without a license?

If they threaten with "i'll go somewhere else if I can't edit my games without paying" then so be it, you're not losing any valuable business, as they clearly stated, they don't want to continue subscribing, but be able to use the software, past the subscription.

signaljacker

There's already a perfect solution to the lockout, that solves all the problems. Resubscribe... and you're not locked out anymore. Easy as that!

If you don't pay you're locking yourself out.

I will still maintain that anyone claiming "lockout" doesn't really have valid reason to make a fuzz. That's just my personal opinion... I just feel that people claiming "lockout" and then tries drive an agenda to get some kind of "free access" after their subscription runs out, why? this is what I don't get..., which I don't think is fair at all for the developers. Why would they spend time to implement special features to allow people to use their livelihood for free, even if it's just small fixes, rexports, to old projects etc?

Personally I think monthly option should solve that. If you just need to make a few minor fixes, a month access for a reduced price instead of a year would seem pretty fair.