1
\$\begingroup\$

I'm working on a multiplayer game and I want to use Flurry to record game events.

In the game you can build, grow and train troops. In Flurry you can log an event (optionally with parameters).

It would be great to be able to track the progress of a player depending upon what kinds of things they build, grow and so on and at what experience levels they do that at, but I don't know whether it's best to just have different sets of events for different types of actions... like this:

NSDictionary *buildParams =
   [NSDictionary dictionaryWithObjectsAndKeys:
      @"Build_Type", @"Castle", 
      @"EXP", @"234523", // Capture user status
      nil];

[Flurry logEvent:@"Build_Action" withParameters:buildParams];

And so on... so another for growing something, another for training, et cetera.

Or is it better to have one global type of record of an event like this:

NSDictionary *actionParams =
   [NSDictionary dictionaryWithObjectsAndKeys:
      @"Action", @"Build", 
      @"Type", @"Castle", 
      @"EXP", @"44234",
      nil];

[Flurry logEvent:@"Game_Action" withParameters:actionParams];

In this method all the data is stored in the one event type. I'm not sure which will give me the best result when it comes to funneling, segmentation, and all that?

\$\endgroup\$
4
  • 1
    \$\begingroup\$ I used Flurry on one of my projects, and the problem I found with it was that it had a maximum events per session. Then it was 200 events per session. So if the player plays for a long time, all of the events will not be logged. Have you come across GameAnalytics? They are especially designed for gaming and have a very handy custom eventing. \$\endgroup\$
    – Esa
    Commented Aug 28, 2013 at 6:09
  • 1
    \$\begingroup\$ Can you point me to where Flurry states 200 events per session? I've not been able to verify this. \$\endgroup\$
    – Phil
    Commented Aug 29, 2013 at 23:31
  • 1
    \$\begingroup\$ I could not find the original location where I came across this information, but I found couple of other URLs: quora.com/Mobile-Analytics/How-does-Flurry-make-money/answer/… and bugs.yoyogames.com/view.php?id=9314#c17516 . Plus I checked my flurry event logs on one of the applications I have and the logs stop at 200 on each longer session. \$\endgroup\$
    – Esa
    Commented Aug 30, 2013 at 5:56
  • \$\begingroup\$ The limit is now 300, from the official site: stackoverflow.com/questions/18517386/… \$\endgroup\$
    – ashes999
    Commented Aug 1, 2014 at 15:50

1 Answer 1

1
\$\begingroup\$

It sounds like you are trying to decide between a system where the event parameter describes a specific kind of event (a build event, a destroy event, a purchase event, et cetera) and one where the kind of event is encoded in the parameters and all events are "game events."

You should choose the first one. The second option discards information and useful querying functionality: when everything is a "game action," there is no point to even having that field in the data, and since everything is a game action there's no way you can usefully query using that field.

Flurry exposes the event name field for a reason. By making it a first-class citizen, it can perform storage or query optimizations on it. It also uses the event name as a way to associate the start and end times of timed events; if you record all your events with the same name, this becomes less useful.

Flurry's own documentation and example event set for a game agree with the pattern of using the event name to actually name each kind of event, as well.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .