cranberrygame thnx for the links. Access to the share widget is exactly what I've been looking for.

Few questions:

1. I respect your work and I don't have any problem to pay for the plugin package. I would only like to verify that I can utilize it the way I plan.

Is it possible that you upload a screenshot of the plugin conditions and actions?

2. On the Pick the Sticks example the share widget is accessible only via the google highscores. Will I be able to simply add one share button that will activate the widget?

3. Are all the features on the sticks app included in the full pack of your plugins? Do all plugins have capx examples?

Hi all

My new game, Froogies, is about ready for test launch. I would like to add a Share feature that will hopefully make the game to spread around.

The Facebook and Twitter plugins may do some of the trick, but what I'm most interested in is an access to the device's share action (via SNS) that suggests many options for sharing (MMS, whatsapp, mail, fb, twitter, etc.).

The only solution I found so far is cranberrygame 's ShareApp plugin. https://www.scirra.com/forum/plugin-cordova-related-c2-plugins-crosswalk_t109586?&hilit=ShareApp (the plug is highlighted at the bottom of the post).

This plugin is not sold separately, only with the entire pack, so I would like to know if anyone have successfully utilized it before I pay....

Ideas for optional solutions are welcome

Thnx

I suggest using local values on webstorage , rather that the save/load procedure.

Since savegame takes a snapshot of the entire game it is prawned to crashes upon update.

On webstorage you may specify the variables you save and load (level, xp, credits, special attribute flags etc.) so this data may be used even if the version update includes different objects or behaviors. In short - save the game variables state, not the game state.

MaorKeshet that seem like over-complicating things a little. For example how do you plan to apply your system with the following conditions:

- layouts are selected at random (random levels)

- not every layout is a level (we have a menu layout, objects layout, etc.)

And come on, it's not the worst thing selecting stuff by name. Look at jQuery - the whole library is built on this principle and it has been the first choice of web developers for years

This method would work the same way when randomizing the layout. Randomizing is actually a lot easier with numbers.... I think that the little extra time that would take to generalize a rule (or to set a unique layout rule) is very beneficial down the road. I use this method for many different purposes: for example, to test different versions of a specific game module ( I can run the very same game mechanics with a completely different "enemy generator" by only changing varEnemyGeneratorVersion on the game's settings).

Group activation/deactivation makes things very tidy, and you may use it in a similar when even if you insist on using names.

Refeuh that seems to be the more organized way to do it (even though using groups can make the events sheet neat as well), and if you have layout count in the vicinity of 10 that's fine, but on a larger scale it seems the more practical way to put everything in a single sheet. And in the case that this does not compromise the performance of the game (thank you ErekT for clearing that out) it's like... why do it otherwise at all?

The only downfall I've encountered is that there is no option to perform event on specific layouts, but with a bit of trickery it can be done. Something like naming layouts "Level1, Level2, Level3, etc.", getting the current layout name, storing it in a global variable and comparing that variable to the layout name:

On layout start:

var CurrentLayoutName = LayoutName

if CurrentLevelName == "Level1" -> do events on this layout in particular

I recommend on using group activation/deactivation in order to apply specific sections of logic to a specific layout

For example:

Name groups Movement_0 , Movement_10 , Movement_20, Movement_30 etc. for the movement mechanism you want to use on different levels (Movement_0 for

levels 0-9, Movement_10 for levels 10-19 etc.)

Add global varLevel (use a number, not text! It is a lot easier to use a number for a mathematical condition that generalizes a usage rule, rather than creating a name condition for each and every layout). Make sure that this variable update as the layout changes

On the common event sheet - on start of layout - add an action that disables all these groups (to disable the group that was active on the previous layout):

On start of layout > System > Repeat (number_of_groups) times > set group "Movement_" & loopindex*10 deactivated

and an activation action that enables the appropriate group:

On start of layout > System > Set group "Movement_" & floor(varLevel/10) activated

This way, adding a new group for new levels only takes a change on number_of_groups value on the disable action, and naming the new group correctly. The group will follow the rule you have defined.

You may use a simplified condition for a single group that should work only on a specific layout:

On start of layout > If varLevel=55 > system > set group Special_55 activated

else > system > set group Special_55 deactivated

BTW - this method would work either on a single or multiple event-sheet structure.

bump

Hi all

I am very close to launching a test version of my mobile game, Froogies At this point I would like to add stats mechanism that will allow me to adjust and improve the user experience and the game's "stickiness" and "virality".

As I started to plan my stats mechanism, two fundamental questions came up:

1. Stats Logical Structure

In my game the player has to make the "Froog" jump and eat "vitamins". As the game goes along:

a. the score goes up upon collecting vitamins.

b. the "froog" might die (3 lives per game, and you may collect hearts that will get you additional life)

c. new levels are opening up (with new types of vitamins)

The questions that I'm trying to answer:

1. How many times will the average user launch my game before leaving it behind for good, and over what period of time? (Retention data)

2. What's the average session length?

3. How many games are played over an average session?

4. What's the average score on the 1st/2nd/3rd/10th game? What's the average level achieved on the 1st/2nd/3rd/10th game? (Progression/Time graph)

5. How many lives are actually played on an average game?

6. What's the average number of "special vitamins" that are collected on an average game?

7. If the Share button is clicked - after how many sessions/games did it happen? what's the user's highscore at this point?

What should a proper set of game stats include? On one hand, I want to know as much as I can about many different aspects of the game usage. On the other one, I don't want tons of data that is too complicated to analyze. Does anyone have a good example of a set of game stats that is proved useful? Is anything of importance missing on my list?

2. Stats Technical Structure

I read the related (limited) materials I found on Scirra's site and the conclusion is that I'm going to use Google Analytics plugin by Sun Temple.

http://suntemple.co/construct-2/google-analytics-plugin/

I'm expecting that most of my users will be kids 6-12 y.o. Kids at young age don't have their device online at many times (since they mostly rely on available wi-fi). This means that in many cases the data will be lost (if base on realtime mechanism only).

I was thinking about a mechanism that stores the stats to a local webstorage when the browser object is not online, and sends the data to GA when online next time. The problem is that with such mechanism I will be getting two sets of data ("Realtime Data" and "Delayed Data") and these are going to be quite complicated to combine.

Did anyone experience a similar mechanism? Any other ideas how to work around the "delayed data" issue?

I would love to hear any comments and ideas regarding Game Statistics and Analytics, and turn this thread into a viable source on the matter. Proper implementation and utilization of Game Statistics is a key factor to success. unfortunately, most of the theory behind it is kept by the large gaming companies, and not available to Indie game developers. Lets change this!

try running the exported images trough pictureslash.com , i ALWAYS get improvements with that, expecially if i have some big images with much details and transparency then it saves between 30-50% of download size compared to the brute png compression of construct2.

30-50% is very significant thnx for the tip. but this will only influence download time, not any run-time performance.

Thnx Ashley.

BTW, this happened unintentionally while tweaking other settings.

thnx Lof

Here's the sections on Ashley's tutorial that answers the question:

[quote:3tjbkg28]The fact most images come out a power-of-two size has another benefit: some platforms, especially mobile ones, only support mipmapping with power-of-two size source images. Mipmapping is a rendering technique that basically enables high-quality downscaling, so objects resized small use real antialiasing to look better. This means after exporting some sprites may be able to resize smaller with better rendering quality on some platforms.

Note that if you set the Downscaling project property to 'High quality', images on spritesheets are always padded out to power-of-two sizes in order to mitigate two minor rendering issues. This negates the memory saving of spritesheets and so should not be used for no reason. For more information see Memory usage.

Changing my settings back to medium quality on Downscaling resolved the issue.

I must admit that I am quite puzzled by the fact that downscaling (which by nature uses less pixels than the native size) effects the memory usage in such a way (more than x2 mem usage! ). Ashley can you clarify please?

Thnx — Since I focus on getting drunk at the moment I will look tomorrow. I did change some project properties...

HNY