Hello all,

This time my question is not a how to, but a "best way to" or "how whould you like to move" kind of question.

Imagine a Bomberman kind of level, topview, relatively a maze but not so tight on movement space.

On that scenario, you move a fast character like a mouse pointer. But this character should collide with the scene's objects.

The question is, How should i make the movement of this character?

My first inclination is to move it with mouse/finger in a 1:1 fashion. Exactly like a mouse cursor.

A second option whould be to click and make the character move to that point (stright without any fancy pathfinding). Like Diablo movement.

The last and most common is to move with a normal virual pad. But my game is more focused on mouse/touch driven movement.

If you want the closest example of my game see: Knights In The Nightmare

youtube.com/watch

You will see how you move some kind of cursor, it seems like a mouse driven movement is the way to go. But collision and lag kill this implementation.

Any ideas about workarounds or ideas for other solutions whould be apreciated a lot!

I believe there's a confusion over what CocoonJs or appMobi do to a C2 project. It seems like CocoonJS or appMobi can make html5 games work with their fixes also as webgames directly embeded on the devices browsers.

But to make it clear to everyone, both CocoonJS and appMobi will transform a C2 project into a native app. But won't fix a game so it can work directly on android/ios browsers with the added functionality of those wrappers. (But it might be really helpful if they could).

Yes, I know that html5 games works everywhere. But my question is more about what platform seems better to work for first.

I don't put IOS browsers as an example yet because it has many problems like no audio and Android has some others as well like no multitouch until v4.0. That gives me two options, Facebook games or a native app (with a wrapper). Also I ask in general, not necessarily in relation to Contruct features.

A native app seems easier but facebook could work better.

What would you do first? (this question is for everybody), a native app or a facebook one?, (the arcade ones not the masive "ville" ones).

Hello All,

Looking how Playfirst failed with their insertion on facebook with some of their successful franchises and, on the other side, looking how some ios arcade games are doing pretty fine on their Facebook versions, i wonder:

What platform should I/We target for? Which brings a better future or probabilities of success? (if the game is good of course).

To give some perspective on this subject:

Angry Birds or Jetpack Joyride are very successful games made first for IOS and then, when those made their entrance in facebook, both worked pretty fine, even when those are clearly more arcade and less "ville" in their gameplay.

At the same time, games that should work better on facebook failed there and worked better on IOS, like those of Playfirst(Cooking Dash).

So it's no more a matter of type of game for the best platform for the particular genre.

Any insight or experience on this, about what world worked better and why please share it.

Also, to add to stream of appreciation for your work (Tom & Ashley), is commendable the level of support and attention for direct and indirect questions and doubts from your community. From direct questions like "do this works right now?" to indirect ones like "how do i do this or that". You appears replying, and fast. This kind of presence is always a measure of health, an indication of a wheel oiled and running fine.

All this, comming from a tool that not only is using successfully new technologies some still even fear to use (html5 games) but, also, doing it with the added hardwork that represent giving this in a non-programmers environment.

I will always defend all approaches to simplicity for complex tasks or projects. And you have developed this kind of tool with the added value of your constant presence and with a quality that, to me, excelled all expectation.

It's on us to make now, good games that reflects the quality of the tools that helped us archive them.

Reading the blog post "The Great HTML5 Mobile Gaming Performance Comparison" (23 May, 2012 wrote by Ashly) It leaves me a doubt:

"Android 2.x is rescued by directCanvas and CocoonJS - both add support for multitouch even if the stock browser does not support it"

This is if I wrap the game to a native form only right? Or this miraculous works if i keep it as a browser-webgame too?

Android in my country just recently sells v.2.3 as a new thing. Waiting for a standar sell of Android 4 smartphones could take some time that i don't want to wait (for multitouch on android browser).

This could add a masive amount of devices to the list of supported devices for browser-webgames.

Thanks in advance for any insight on this.

Downloaded, i have a question about your implementation:

It works even if i put fullscreen a web browser on ios/android/pc?

Also could be any problem if an application is ported to native with wrappers like cocoonJS or appmobi?

If it works "no matter what" it's really a time saver.

Cheers for the new release!

Excelent contribution. I don't know why it hasn't more atention or replies. <img src="smileys/smiley22.gif" border="0" align="middle" />

To close as solved I recap:

1) how do you overcome the nightmare of having different audio formats for different browsers? (especially with ios's safari).

2) When you make a webgame for pc and also for ios web browsers, how do you manage the dual controls scheme when there's no 1:1 correlation between pc controls and ios heavy use of touchscreen?

A)

1)All audio problems are easily solved in any situation/device/platform just using Construct 2 dual-enconding feature (W7 Only) and wrappers for ios browsers. Dual-encodig works in any situation.

2)If controls are easy to replicate then use C2 methods described in tutorials and blog. But if the controls are too dispar then a dual project could be more manageable in the long run.

Workflow for webgames so far:

1) Develop for pc, keep controls in mind if you intend to export to ios.

2) If you develop under windows 7, any audio issue across browsers and devices will be automaticly fixed with C2 dual-encoding feature.

For other OS, you need to do this by yourself.

3)When you want to export your webgame from pc to ios make it as a separate project or see tutorials for ways to detect devices and use only one project/code for any end device/platform.

4)Export your final project to ios using a wrapper, PhoneGap for easy casual browser games (given it's slow) or directCanvas/CocoonJS for speed and more "native" games (as those doesn't use ios browser).

THE END

Thanks Ashley and Sqiddster for your atention to my questions!

First, thanks for the quick responses.

1)That dual-encode is pretty good stuff to have. It solves this problem. I'm using windows 7 so this issue is gone for me. Good work Scirra on this one. But a question anyway:

This dual-encode works too using those below-mentioned wrappers for ios browsers?

1)b) I know about the wrappers, that is the only way to go so far.

Isn't Construct 2 already capable of exporting using those wrappers?

I belived that appmobi was more or less done in the last release of C2 and CocoonJS was in testing phase for android apps.

How's the development going for this kind of "html5 to native" solution?

Using of course those mentioned wrappers.

2)Sqiddster is one of those users I take as a reference about the way to go. So you say it's better to make a dual project instead of losing hair detecting devices in-code? So far this is my approach since probably other areas will suffer severe changes in format too.

I'll check those methods you mentioned Ashley, just to have all grounds covered.

To extend the question in 1b, If I export using a wrapper like, say, directCanvas, I gain audio and speed, but there's a stopper somewhere? Some feature unsupported or any side-effect in the process?

Last about the wrappers,

Can be used with constuct 2 to make native apps and ios webgames or works just in one front only?

Thanks in advance, i found no other reasons or walls on my way if those questions are answered in a positive way. Fingers crossed!

Hello everybody!

Two questions related to the best way to port the same webgame to pc and ios web.

1) how do you overcome the nightmare of having different audio formats for different browsers? (especially with ios's safari).

Since appears to be no one-solution format, how do you conform to all?

1)b)Somebody found an easy workaroud to the lack of audio on ios safari? Some I found in the community works but are a pain really.

2)When you make a webgame for pc and also for ios web browsers, how do you manage the dual controls scheme when there's no 1:1 correlation between pc controls and ios heavy use of touchscreen?

I think the answer is to have a "Case" or many "if" here and there but maybe there's a more manageable solution. Some kind of master controller that switch "versions" depending of the platform initiating the game.

Very lost in portability techniques. Any help would be appreciated a lot.

John.

When i see this engine and many others i see in this one a lack of IOS export and compatibility in the frontpage. A quick look should reveal that IOS games can be made with constuct 2 but that doesn't shows until you look deeper and even then is somehow elusive.

I think it would be very important to show much more about compatibility, maybe as a pane like those that say Box 2d Physics, Facebook Games, Chrome Webstore, etc.

also some more flashing around the concept of "develop once play everywhere" and speed of html5 games on IOS browsers.

Any Social "ready to use" feature should explode in many colors too, like that pane saying Facebook Games, with enough info about capabilities and features. Online Score, compatibilities with this or that social platform and such.

Basicly an exaltation of the posibility to make the games that everyone is playing. Dissect one and see what make it a winner, and if the feature exist, show it big.