How are project's asset files handled exactly by construct3?

We found that it can save to the cloud - to third party services such as dropbox and onedrive. To save locally, construct3 downloads a zipped project folder.

This however leaves the question of game assets. How do you import them, how do you edit them and iterate?

Lets say you have a bunch of sprites that you want to edit with an external app, after they are already in the game. Can you simply open the files that construct3 is using directly,then do your changes and hit save? Will construct3 automatically reload those assets? Where are those assets? If they are on the web, they probably get downloaded/uploaded by dropbox or whatever service you have?

Or do you have to go through some kind of a process where you download your project, unzip it, replace the files, reopen the project... I am confused

What happens if you dont have any internet connection or you are not using a web host?

Dropbox recently dropped support for direct linking to files. Does that affect construct3?

Scirra should compete like crazy if they want to succeed with that rental model.

Right now the export process will be improved, but using the same old wrappers will result in the same old slow under performing and over sized apk games.

That really makes it fall far behind all the other game engines on the market- if the intent is making mobile games.

If it can't export an apk that runs at normal speed - the same speed that you get when play testing - It's still just a toy for prototyping.

From my point of view - that sort of makes the rental price crazy as a proposal. You can buy a lifetime license for almost the same amount for an engine with event sheet even - that does export to native android apk - no wrappers needed.

Even stencyl- which has the same license doesnt need wrappers to create an apk.

Even with a nicer to use editor - if the end result is slow or broken, it's really not competitive on the game engines market.

You have to be either biased or blind to choose it over the competition.

If scirra comes up with a wrapper that is tiny and fast - they might have a chance. Otherwise the target user will continue to be hobbyists or people who just want it for prototyping - people who cant justify spending 99$ per year for something that gets them less or no income in return

clickteam fusion has had a builtin plugin manager for ages

All the plugins that are listed in it are free.

it's right in the editor- it lists, updates and downloads plugins to your project with zero configuration needed by the user.

Separately they also have a store, which is used for premium plugins

Godot also recently got a plugin manager that gets them straight from github.

Most game engine editors nowadays have a built in plugin manager that can fetch them from a repository.

Construct2 has lots of community made plugins and even a couple of community made managers - but scirra has not done anything about managing them - so some of them are now on dead links. The editor has no infrastructure made for fetching plugins from an official repository!

I find the lack of a plugin manager strange and would love to see construct3's editor finally get one

I'll be absolutely honest, I took an old game with a lot of badly optimized code, HD screen resolution intended for desktop-only, loads of layers and extensions (even some 3rd-party that weren't comparable with the exporter and wouldn't build) in Fusion 2.5, and slapped on a thumbstick and compiled my very first ever android apk in F2.5. And it worked. Flawlessly. Perfect performance. Smooth fps and gameplay. First. Apk. Ever.

I've build hundreds of apks in Cocoon, Phonegap and XDK. And none of them have come out well. So far, my only "succesful" compile with cocoon on GooglePlay doesn't even work with some phones (thanks to cocoon, XDK was painful slow).

That's just my experience though.

I had a similar experience

packaging a construct2 game + xdk = a super slow when ran from the installed game, but normal speed when running from localhost. So when you playtest with localhost you get different performance from waht you actually get when you export the game to an apk - inside a wrapper

Exporting a fusion 2.5 game - when playtesting fusion creates a native apk and moves it to the phone via the usb cable, then runs the apk. So what you get when playtesting is the same as what you will get in the final game - and the speed/framerate was much better than construct's wrapped in xdk game apk.

I think the low performance in construct2 games installed via apk is the wrapper. I tried it only with xdk, havent tested with cacoon.. That was a while ago though. Since then maybe xdk got faster?

Native built games will always outperform games relying on a wrapper, because they dont have an extra software layer to talk to the hardware.

A good question to ask is - will construct3 editor be able to export to html5 without using any network service, and allow the user to wrap the game with xdk/cacoon the same way construct2 does?

Maybe for most Construct users, using C3 locally is not an issue. However when you are like myself and regularly on the move it is nice when you can open C3 on every computer with internet with your account.

The mobile thing is definitely a big plus that it has! I really like the idea of tinkering with the event sheet anywhere I am - on my tablet or on my phone even!

But it is also something that a lot of people seem to be afraid of, because they assume that because lives on the cloud ,it will stop working for them when the service is discontinued or offline somehow .

That is partly due to the subscription licensing model as well, but it is what it is.

First impressions might be wrong. There is a lot to love about the engine. It is definitely evolving in the right direction if the focust is html5. Making the actual editor html5 makes a lot of sense to me.

I'd say that Tom and Ashley made the right call on that.

It will give the engine some web related and collaboration advantages that native editor engines can not do as easily and well.

Real time collaboration for example is a very possible thing already:

http://superpowers-html5.com/index.en.html

I am eager to see if scirra tries to do that with construct at some point too.

Being html5 doesnt mean that it must be a subscription based service that is hosted on some scirra server that people HAVE to rent out. I think it is just a licensing/marketing approach that scirra wants to try out

Superpowers for example can be hosted from a local machine and accessed via a web browser by other machines via localhost - the same way that construct2 creates a localhost to playtest a game, construct3 could create a localhost of itself that other users on the network could access to collaborate on a project!

THAT would make it kick some serious butt on gamejams and literaly give it superpowers <img src="{SMILIES_PATH}/icon_mrgreen.gif" alt=":mrgreen:" title="Mr. Green">

But seeing the licensing model that was announced, I am rather skeptical that they would give that freedom to their users. Although - hosting the game editor and engine could be set to a limited number of seats and scirra could sell the number of seats that a licensed user can host. Just throwing out some ideas here

You might be able to get some of the functionality there via plugins?

Godot and unity both got some of the level editing stuff via plugins already. Godot has several!

They are open source, so you maybe we can study how they work

http://godotengine.org/asset-library/asset/59

https://github.com/arypbatista/godot-bo ... polygon-2d

https://github.com/RodZill4/godot-platform2d

So it's just a matter of time someone writes a similar thing for construct in javascipt?

Btw there was a petition to open source that ubisoft engine (ubiart):

https://www.change.org/p/yves-guillemot ... rce-engine

Regardless of how many people signt it, that will never happen <img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing">

The only one advertising anything to sell here and arguing about which engine came first appears to be you.

Have a good day!

If you think about it, it doesn't really matter which one came out first and each of the three has an advantage or two over the other two.

I jumped on the whole topic of engine comparison because other users in the thread noted that fusion 3, construct 3 and godot 3 are three engines with the number 3 version that will compete this year So like commenting on race horses I pointed out what I think about the three at the moment

Tom very rightly sneaked in the half life 3 confirmed joke in there too

Engine history and design really fascinates me. I like the topic very much and have been interested in visual programming approaches for ages. It is what got me into learning programming in the first place. I have both construct2 and fusion to thank for that and respect both projects, regardless of what i bring up about one or the other - i try to restrain myself from showing bias, while compiling information that would help me or others decide which to use for their project.

On the topic of which came first - I simply tried to keep you on the fact that I was talking about the visual event sheet specifically, and you kept pushing away from it - to make it sound like my claim is that clickteam somehow invented programming languages and 2d game engines in general

zenox98 You are right, this thread is going way off topic. I wanted to say that the future is not dark, because game development is becoming more and more accessible - to OP. More choice of engines, better engines and ways to publish your game.

lamar then jumped on the opportunity to start plugging his tool by making the point that what he is doing with it is the general direction of where things are going in gamedev.

The truth is that OP is concerned about the licensing model of the potential that one day he will not be able to open his construct3 projects, because construct3 is a tool that exists in the cloud - and it periodically checks with scirra if the subscription is paid. Thus is one day the servers go down, his offline copy will stop working and his projects will be dead

> lamar setting sprites and how it looks like is not really game design.

> The design of the game is where you establish the rules of its world, the conditions of things to happen.

>

> A level editor will lock you to a genre, because the game loop can't be changed. For example you can't make a top down game with your platformer level editor. You can't add new mechanics to it - such as shooting or new types of enemy behavior.

> As a result a game made in it - is not a new game. It's just a level

>

You seem to be missing the big picture sorry. I can expand that same model of visual design to any game genre including RPG, shooting or something you create yourself. and that can all be packaged with one game engine like C2 running in the background.

Because of the memory limits of the arcade my sandbox is limited to platform design but the final product will include RPG design and other genre's and all can be modified very specifically to your design desires.

The basics of all game designs revolve around setting sprite effects and behaviors and setting the mood of the game through music, sound effects and graphics and engines are all just there to process the routine events you selected.

ADDED: Unlike a level editor the sandbox designer will allow you to incorporate any game genre into the same game and you can start as a platformer that evolves into an RPG with side missions using first person shooting or some other genre and it will all be in the same game with smoothe transitions from one genre to another.

It is a visual based toolbox for game designers with room to add new behaviors and effects when ever they are created for the game engine.

Wait there for a second. Are you by any chance talking about something you made/making?

Is the sandbox some tool that you are building?

lamar setting sprites and how it looks like is not really game design.

The design of the game is where you establish the rules of its world, the conditions of things to happen.

A level editor will lock you to a genre, because the game loop can't be changed. For example you can't make a top down game with your platformer level editor. You can't add new mechanics to it - such as shooting or new types of enemy behavior.

As a result a game made in it - is not a new game. It's just a level

lamar

The problem with relying too much on out of the box type engines is that all the games using them are cookie cutter stuff. If you are a fan of that stuff - perhaps you might like rpg maker. It still supports plugins - very similarly to construct2 - written in javascript.

But all games made with it - look like they are made with it.

With the case of a level editor type engines - it is obviously a level editor. That is a huge difference from a game engine.

Construct is a game engine, because you can set the design of your game and be specific.

A level editor only allows you to set the layout of levels, not the design.

In Construct you have reusable out of the box logic in the toolbox - game objects with builtin functions.

But such is the case with most other game engines out there.

Fusion 3, godot 3 and construct3 all have premade game logic that the programmer can use to build custom games design. Out of the three Godot has the largest number of objects - called nodes there.