Jump to content
Double Fine Action Forums
Sign in to follow this  
DF Oliver

Programming Update #2

Recommended Posts

I see on the Moai web site that games made with it run natively on phones, but on the desktop they require the Chrome browser. I hope you're planning to make the game run natively on (what I consider) the main platforms?

Share this post


Link to post
Share on other sites

As far as the data usage is considered, if you people don't want it, most likely you can turn it off.

Share this post


Link to post
Share on other sites
I see on the Moai web site that games made with it run natively on phones, but on the desktop they require the Chrome browser. I hope you’re planning to make the game run natively on (what I consider) the main platforms?

Moai supports Google Native Client (NaCL) on the Chrome Store but does not require it (DFA definitely will not require it). We currently have the game running native on PC, which you can actually see snippets of on Oliver's computer in the Moai testimonial. Moai also supports native Mac and, with a bit more work, Linux, which is one of the reasons we chose it.

Share this post


Link to post
Share on other sites
To be honest, I was kinda hoping you guys would develop your own Adventure game engine (and either keep it proprietary or open source it whatever) with respective features and maybe its own scripting language, which could be used as a jump-off point for any future Adventure game undertakings that will hopefully follow xD

That's actually not so far from the plan. We'll definitely be writing a lot of adventure game code and tools for DFA, code that will be very useful for future adventure games, not just DFA. What we're not doing, which is nice, is re-writing basic building blocks like building dynamic vertex buffers from homogenous sprites, writing a C++ reflection/binding system for Lua, etc. etc.

I don’t know much about Moai, especially in regards to adaptability and flexibility using it for certain tasks, but let’s say what has already been produced with it doesn’t fill me with the utmost confidence as everything so far seems to be iOS/Chrome/Android games: http://getmoai.com/made-with-moai.html

I wouldn't worry about that. Moai is very new, so there's not a very large body of work for it and much of what there is are early prototypes. We wouldn't use it if we weren't confident that it would meet the needs of DFA, and of course we have 100% of the source and can ensure that it does whatever we need and want it to do.

Share this post


Link to post
Share on other sites

I am thrilled to see these tech updates going up. This is the kind of details I didn't think would be given enough attention in the video updates. :P

Share this post


Link to post
Share on other sites
Okay, it sounds like you guys are going to have a in-game Hints system like Telltale has. If you do have an in-game Hints system...

I just want to be clear that we haven't made any real decision on if we'll have that kind of hint system yet. We're still focusing on figuring out the core game :) I was just trying to list a few ways in which it might be possible to modify an adventure game post-launch that helped frustrated players without making any fundamental changes to the core adventure game and it's puzzles.

Your points about an opt-out hints system are all well taken, though. We'll be sure to keep them in mind when it comes time to discuss if and how we want to use such a system in DFA.

Share this post


Link to post
Share on other sites

This was so interesting I got stuck in the if statement and was forced to read the post over and over again!

Thanks for a great post, I'm glad you are going for open source.

Share this post


Link to post
Share on other sites
I’m really glad they’re *not* going from scratch. This way (bug fixes aside) all the time and money that would be sunk into getting the basic building blocks in place - defining and rendering a scene, animation, infrastructure for the game mechanics (and remember, they have to get it working on 5 different platforms) - can be spent on the mid and high level stuff that actually make for an awesome game.
I’m happy that an existing engine is being used for the game as that to me means that more of the development time and money can go into the actual game (story and puzzles and what not) instead of having to take time and money to make a new engine. The fact that the engine is open source and so modifiable just sweetens the deal.

This is very much what we were going for. Use existing tech so that we can spend more of our time (and your money!) on the really important, interesting, creative parts of the game.

Share this post


Link to post
Share on other sites
Out of interest, is there interest in sharing anonymous data with the backers?

Good question! I honestly have no idea. But it's a good thought and I'd bet we'll share the data or our learnings if it turns out to be super useful.

At least I think it would be nice to use and share such data with the backers during alpha and beta tests :)

Share this post


Link to post
Share on other sites

PS - I'm not ignoring the large block of analytics/metrics related comments. Brandon will have a follow up post on that after lunch. I'm trying to respond to the various engine/tech related posts to make sure they don't get lost in the shuffle of a cloud-troversy.

Hah. Cloud-troversy. Hilarious.

:)

Share this post


Link to post
Share on other sites

This was a great read. I hadn't heard about this engine before, so it will be interesting to see what it can do.

Share this post


Link to post
Share on other sites

Howdy, folks! Thanks for the welcome. I'm so excited to be working on DFA.

As far as metrics go, I'll tell you what I get excited about collecting: crash reports and performance statistics. Making sure that the game runs well for everyone is a big challenge, especially on PC and Android, where people have extremely varied hardware setups. Double Fine is a small company without a huge testing lab, so it's very helpful for us to get data back from the wild about how well the game is working for everybody.

Fortunately, we're shipping on platforms where it's easy to push updates, so we'll be able to respond to problems that crop up for specific hardware configurations. This is much easier for us to do if we have raw performance data. Otherwise, we have to rely exclusively on forum posts and support requests (which most people don't bother with when they run into problems).

Anonymous play stats like puzzle completion time are also interesting, especially during development, because they can help us check our design assumptions against empirical data. They're less interesting after the game has shipped; puzzles and story are tightly interwoven in adventure games, so it's difficult (let alone disappointing) for us to make big structural changes afterward. That said, I'm sure we could learn a lot from the differences between backer play stats and play stats for the general public. Information like that could influence the development of our future games.

Other personally identifiable information is deeply uninteresting to us. It won't help us make better games. We won't collect it.

The game also won't require a live internet connection to run. That'd be lame.

And thanks for voicing your concerns! As a fellow privacy wonk, it's much appreciated. We don't have a specific plan in place yet, but it's an interesting area for us to explore during development. We'll continue to keep you updated as we work out more details.

Share this post


Link to post
Share on other sites

Related to the question of opt-in or opt-out for sharing data stuff, I feel compelled to weigh in. Full disclosure: I make my living working for a company that sells and publishes Ads on the Internet, and as part of that, we engage in targeting.

Any system that is dependent upon user participation to be effective (this includes data collection in games, as well as things like Pensions), can only reach it's ideal potential if a user is automatically opted-in, unless they explicitly opt-out. Most people don't really have strong enough opinions about something to choose to take action on it, and while they wouldn't be opposed to participating in the system, if they need to opt-in, they never will, because people are lazy and don't want to do extra work. This idea is particularly notable when looking at something like 401(k) participation when comparing opt-in vs. opt-out strategies( http://www.sharebuilder401k.com/auto-enrollment.aspx ). The high base-rate for participation in this case is because the benefits of opting-in are more tangible than they are in data-collection operations.

And in games, there is a TON of useful data to be gleaned by collecting anonymous data about user experience. If 65% of your users are failing to make it past a certain part of the game, odds are that part of the game needs to be revised, especially if it's early on in the experience.

I do believe that anyone engaged in collecting user data should provide an opt-out mechanism for those users who don't wish to participate, but the mechanism MUST be opt-out in order for it to be worth implementing at all.

Share this post


Link to post
Share on other sites
[...]The game also won't require a live internet connection to run. That'd be lame.[...]

Thanks for clearing that up. While surfing to the moai site I discovered their "game logic in the cloud" concept and felt the strong urge to ask exactly that question :)

Great updates so far!

Share this post


Link to post
Share on other sites
And in games, there is a TON of useful data to be gleaned by collecting anonymous data about user experience. If 65% of your users are failing to make it past a certain part of the game, odds are that part of the game needs to be revised, especially if it's early on in the experience.

I highly dobt that - and here is why:

Let's say you know:

- Number of wrong attempts to solve a puzzle

- Time spent trying to solve the puzzle

- Success (Succeeded / Quit the game)

What you do not know from this data - and for a game this is the most important thing: Did the user have fun trying? User A may be happy trying to solve the puzzle for several hours, exploring all angles and talking to a lot of NPCs trying to figure it out whereas another user may get frustrated after only a minute. So, what is the right amount of time a user should spent trying to solve it? If the time is too short, a lot of users feel the game is too casual and streamlined. If it's too long a lot of users may get frustrated. I don't think there is a "right amount of time spent" and therefore I don't think that it would make sense to collect the data at all.

And also: Numbers lie. You don't know how was playing at the time (the main player, his/her partner, a child), you don't know if the player resolved to use a walkthru just after a few minutes and misinterpret a short solving time as a success whereas in reality the player may have been completely clueless.

Emperical studies are not an feasible equivalent for good playtesting and certainly not for a good game design.

In the interviews Tim and Ron stated something that they only had limited playtesting for the goold old classics (and they certainly did not have any form of automated feed back from the whole user base). And these games turned out to be just fine.

And last but not least: It's still expensive! If you have a huge pile of statistical data you will have to spend time and/or money to make it readable. Even if you have the tools it will still cost time to draw conclusions - and they may be the wrong ones. Example: In their Building Windows 8 blog Microsoft stated on a lot of occasions that ther UI design - espcially the "beloved" ribbons - are a direct product of automated measuring usage information. Worked out so great.

I can get onboard with crash reports - but they can just plainly ask after the app crashed. If it does not crash and performs good there is no real need to report that. Also - at least android - delivers anonymous crash info without the need for another reporting tool.

Share this post


Link to post
Share on other sites
Other personally identifiable information is deeply uninteresting to us. It won't help us make better games. We won't collect it.

The game also won't require a live internet connection to run. That'd be lame.

Thanks for the clarification! But it's funny: I never heard someone state "Yeah, of course, we collect as much personal data as we can and try to build user profiles from that" right up front - normal that statements is uttered only after the privacy breach was proven.

That being said: I am not really concerned about DF misbehaving like that - otherwise I wouldn't have given you the money up front ;-)

Share this post


Link to post
Share on other sites
And also: Numbers lie. You don't know how was playing at the time (the main player, his/her partner, a child), you don't know if the player resolved to use a walkthru just after a few minutes and misinterpret a short solving time as a success whereas in reality the player may have been completely clueless.

Most of these issues are improved by simply having a larger sample size. Outliers are excluded from statistical analyses for a reason. Numbers don't lie, they're just points on a line. Bad analysis leads to bad conclusions. Data collection needs to be done carefully, you need to know what you're looking at to make sense of it.

Also, these sorts of metrics generally shouldn't drive your decisions directly, but they can be incredibly useful in identifying the places where your attention should be focused. The data highlights potential problems, but you absolutely need to examine the context.

Even if they only collect this data during the Beta, it's still valuable data to collect.

Share this post


Link to post
Share on other sites

Considering some of the discussions on this thread I thought I'd add a bit of information. This comes from an evening of looking at the Moai engine as it looked interesting and I like poking at new game engines.

Moai is a low level game framework. It's not really even a game engine, but rather a set of tools that allow a game engine to be built quickly and easily with a lot of functionality exposed to lua. While Moai does provide a way to test code written in Lua the testing framework isn't suitable for commercial production.

So Moai provides a way push pixels onto a scene, move them around and accept user input (and many other things) but does not provide a default game style (unlike say the Unreal Engine which is geared to 3D shooters though it can be made to do other games). This saves Double Fine a lot of time but gives them a lot of flexibility to glue these framework components together in a way suitable to the adventure game genre, but they sacrifice things such as advanced toolchain workflow and nice shiny editors that higher level products would provide.

The cloud stuff is purely optional. Games using the Moai framework don't have to touch the cloud, but it provides extra capability to the game creators as well as providing Moai with their business model. Moai is free and open source, so anyone can use it without paying a cent. The cloud element provides Moai with something that they can sell (access to servers etc), allowing them to continue to exist as a company.

The already published games are more indicative of the design choices and ability of the company that made that particular game, and does not speak to the potential quality of a game made using the Moai framework.

Kieren

Share this post


Link to post
Share on other sites
Considering some of the discussions on this thread I thought I'd add a bit of information. This comes from an evening of looking at the Moai engine as it looked interesting and I like poking at new game engines.

Moai is a low level game framework. It's not really even a game engine, but rather a set of tools that allow a game engine to be built quickly and easily with a lot of functionality exposed to lua. While Moai does provide a way to test code written in Lua the testing framework isn't suitable for commercial production.

So Moai provides a way push pixels onto a scene, move them around and accept user input (and many other things) but does not provide a default game style (unlike say the Unreal Engine which is geared to 3D shooters though it can be made to do other games). This saves Double Fine a lot of time but gives them a lot of flexibility to glue these framework components together in a way suitable to the adventure game genre, but they sacrifice things such as advanced toolchain workflow and nice shiny editors that higher level products would provide.

The cloud stuff is purely optional. Games using the Moai framework don't have to touch the cloud, but it provides extra capability to the game creators as well as providing Moai with their business model. Moai is free and open source, so anyone can use it without paying a cent. The cloud element provides Moai with something that they can sell (access to servers etc), allowing them to continue to exist as a company.

The already published games are more indicative of the design choices and ability of the company that made that particular game, and does not speak to the potential quality of a game made using the Moai framework.

Kieren

This is a great post, and very accurate. Moai is a framework rather than a full-fledged "engine" in the sense of Unreal or Source or Unity. We have a huge amount of flexibility in terms of where we can take it.

As a wacky example of a totally different kind of game created with Moai, here's my team's game from the recent What Would Molydeux? 48-hour game jam in San Francisco:

wqR5SmJLH2A

There were a few Double Fine folks on the team!

Share this post


Link to post
Share on other sites

The right eye of the left head of 2HB is a camera, so please put some pants on before wearing the backer t-shirt.

Ok, time for the serious me to take charge:

I think data collection in alpha/beta is fine and even needed in some level. Something that will make it easier for players to accept is to display results of statistics somewhere to the backers.

Replay capability is also something that could be helpful, it can make reproducing bugs much easier.

Maybe also give out rewards, virtual points and alike are surprisingly motivating people.

For the really paranoid, give the option to manually send results, but as long as DF is not in the business of selling our info, but rather making games, I don't think it's something to worry about.

Share this post


Link to post
Share on other sites
Howdy, folks! Thanks for the welcome. I'm so excited to be working on DFA.

As far as metrics go, I'll tell you what I get excited about collecting: crash reports and performance statistics. Making sure that the game runs well for everyone is a big challenge, especially on PC and Android, where people have extremely varied hardware setups. Double Fine is a small company without a huge testing lab, so it's very helpful for us to get data back from the wild about how well the game is working for everybody.

Fortunately, we're shipping on platforms where it's easy to push updates, so we'll be able to respond to problems that crop up for specific hardware configurations. This is much easier for us to do if we have raw performance data. Otherwise, we have to rely exclusively on forum posts and support requests (which most people don't bother with when they run into problems).

Anonymous play stats like puzzle completion time are also interesting, especially during development, because they can help us check our design assumptions against empirical data. They're less interesting after the game has shipped; puzzles and story are tightly interwoven in adventure games, so it's difficult (let alone disappointing) for us to make big structural changes afterward. That said, I'm sure we could learn a lot from the differences between backer play stats and play stats for the general public. Information like that could influence the development of our future games.

Other personally identifiable information is deeply uninteresting to us. It won't help us make better games. We won't collect it.

The game also won't require a live internet connection to run. That'd be lame.

And thanks for voicing your concerns! As a fellow privacy wonk, it's much appreciated. We don't have a specific plan in place yet, but it's an interesting area for us to explore during development. We'll continue to keep you updated as we work out more details.

Thanks for the great post!

I love the effort you guys put in to communicate openly.

Share this post


Link to post
Share on other sites
Again, this really is increasingly tiresome rhetoric around things I never actually said, and doesn't even slightly answer the point that I was actually making, which was that a lot of people don't really care what they're opting in/out of and will always opt out given the choice.

Sorry, but diminishing privacy-concerned people as problems isn't a really good entry point for a discussion.

I can see your point and also think that such information is interesting for developers, but it is and will be misused by managers and/or marketing - Near-always. I don't know HOW often I had discussions with customers about topics like that "Why can't we keep the collected personal and email addresses after use?" "But, we want to know more about the people who registered" "But we won't do anything illegal with them - just put the information in a database and use it in the future for a mailing." "What? We can't do that? It's illegal? Hm, how about we just wait a few months and mail them, when the people don't remember any more where they entered the data"

Always. The. Same.

A simple to implement good practice: Explain what you want and ask people to co-operate. It's really that simple.

Our let me put it like this: Why should the user trust the developer that they handle the gathered information responsibly if the developers don't trust the users to opt-in?

Sorry I didn't respond right away, I had a bit of an evening. Anyway, thanks for your response -the reason your other replies frustrate me is because usually the only reason I get into these discussions is to understand a position better, and well... you didn't seem to be attempting to understand mine, before. I don't think we're actually a million miles away from each other, it's just that I happen to disagree with the 'Always the same' cynicism. For a start, Tim and Co ARE the management here, and I'd be very surprised if they were even in the slightest bit interested in gathering any more personal data than that which is used to deliver the rewards. Maybe I'm wrong there, but it seems to me that 'always the same' is needlessly cynical. And I understand the value of assuming the worst here, but not to such a degree that legitimate uses of data are closed off or hobbled.

Perhaps making it opt-in isn't a big deal - perhaps it is, there haven't been any studies I'm aware of that really look at how it might affect the sample, so we're really just guessing on that one. But my main point was simply that starting the discussion on the assumption that collecting data is an inherently suspicious activity is, in many ways, as unhelpful as expecting users to give up their personal data unquestioningly. I think there's a good middle ground to be found, and I think that it's possible to talk about these things sensibly and without blanket statements.

Share this post


Link to post
Share on other sites

An opt-out feature for the cloud thing would be much appreciated. I don't mind things like crash data etc, but knowing that the game is timing me and sending that stuff to be used as statistics doesn't feel right. I like to take my sweet time playing adventure games and just the thought of timing me solving puzzles would probably stress me out, even if it's anonymous. The stats will just show numbers anyway, not reflect my actual enjoyment of the game. What looks like me being stuck might actually be me wandering around enjoying the scenery or something :)

Share this post


Link to post
Share on other sites
I believe harebrained schemes which did the shadowrun returns kickstarter is using moai as well and has been for a while

That is correct. In fact, they created Crimson Pirates, the first game to ship on Moai, so they are sort of the Patient Zero of Moai.

This is one of the nice things about building on an open source engine - we can benefit from fixes they make and they can benefit from the ones we make, too. We're already starting to think of ways that we can coordinate with them and Zipline (makers of Moai) so that we don't all write different versions of the same feature but can save each other time (Linux port being one of many examples).

That's really cool, the two kickstarters I backed both using the same technology. :D The thought that you might be mutually benefiting like this is just so awesome.

Share this post


Link to post
Share on other sites
Considering some of the discussions on this thread I thought I'd add a bit of information. This comes from an evening of looking at the Moai engine as it looked interesting and I like poking at new game engines.

Moai is a low level game framework. It's not really even a game engine, but rather a set of tools that allow a game engine to be built quickly and easily with a lot of functionality exposed to lua. While Moai does provide a way to test code written in Lua the testing framework isn't suitable for commercial production.

So Moai provides a way push pixels onto a scene, move them around and accept user input (and many other things) but does not provide a default game style (unlike say the Unreal Engine which is geared to 3D shooters though it can be made to do other games). This saves Double Fine a lot of time but gives them a lot of flexibility to glue these framework components together in a way suitable to the adventure game genre, but they sacrifice things such as advanced toolchain workflow and nice shiny editors that higher level products would provide.

The cloud stuff is purely optional. Games using the Moai framework don't have to touch the cloud, but it provides extra capability to the game creators as well as providing Moai with their business model. Moai is free and open source, so anyone can use it without paying a cent. The cloud element provides Moai with something that they can sell (access to servers etc), allowing them to continue to exist as a company.

The already published games are more indicative of the design choices and ability of the company that made that particular game, and does not speak to the potential quality of a game made using the Moai framework.

Kieren

Wow! Thanks for that. I was feeling put-off by the lack of a more technically focused description of the Moai SDK on their web site. This helps a ton.

Seth

Share this post


Link to post
Share on other sites

Ahhhh, so you're THAT Oliver! Funny tall guy translating to German in the KS update video! Now I know what accent to use in my head when I read your posts.

Thanks for the update! And during your honeymoon too!

Ya know, now that I have kids, working a bit during the honeymoon really doesn't sound so bad. It's better than working lots during their childhood (and probably more productive). And when your done, hay, you're on your honeymoon! A bit of perspective ... in case you're in the doghouse with your honey for working. ;-)

Seth

Share this post


Link to post
Share on other sites

Excellent. Moai looks like something I'll probably even use myself when I eventually get around to experimenting with writing games... once Linux is a first-class citizen. (I normally make GPL-incompability my first criteria for dismissing an option, but I doubt I'd need to link against external code when using Moai.)

[old question removed once I saw it had already been answered]

I know Hare Brained Schemes was talking about Linux support not there for Moai yet, will this affect DFA's linux status? Or will you guys help with the Moai to linux porting?

It's not there yet, but it's not so far away, either. We definitely considered this in the evaluation. Many of the sub-systems already work on Linux or can be made to work with pretty little effort. The main challenge will actually be determining how to support the one-zillion-and-three different distros of Linux. Do we just release all the source? Do we just do precompiled binaries for the most popular distros? All that is still very TBD. Fortunately, we don't have to figure that out for a while yet.

In short, no, it doesn't change our plans for DFA Linux at all, and we will definitely contribute work to the Linux port as appropriate.

From what I've seen with games in the Humble Indie Bundles, here are my recommendations for successful approaches to a Linux release:

1. Make a single static build, release it as a .tar.bz2 archive you just unpack wherever and run... possibly with an optional install script to integrate it into the user's launcher menu by installing a .desktop file. (It grates on me to have to run some 3rd-party installer which could be installing who knows what clutter into my system. A game that runs where it's unpacked and integrates via a script I can open up and read is easy to uninstall and easier to trust.)

That's the simplest compromise for you that Linux users will see as acceptable. It's an inconvenience to install, but people will understand that not everyone has time to make and test a forest of package formats. It wastes space by bundling pretty much everything your game depends on, but you only need to build one copy of the game and it's also, in some ways, possibly more future-proof. Finally, it lets us remain in control of what gets installed where on our systems.

It's still a good idea to do at least preliminary testing on major distros to make sure you didn't miss a library or mess something up though.

2. Make and test .rpm, .deb, and .tar.bz2 files for x86 (32-bit) and x86_64 (64-bit) Linux and test them on, at minimum, Debian, Ubuntu, Fedora, OpenSUSE, and a few of the other most-used distros like Arch, Slackware, and Gentoo.

Obviously, this option is a more involved process since you'll be building separate packages for different platforms, but you'll still want to bundle your libraries since, as shown by old Loki software games, Linux platforms often don't have mechanisms you can rely on for ensuring your dependencies will be available in the packaging system until the end of time.

3. Recognize that people are going to pirate anyway, release the source code, and sell/license the bundle of resources necessary to actually make it do something.

When you get right down to it, if you pick an appropriate license for your open-source code, this is like selling a game where there's a modding API and the copy protection was cracked on release day but better since end users can port to new platforms and share bug fixes. People will still buy it as long as the price is reasonable, jerks, try-before-you-buy-ers, and kids without credit cards will pirate as usual, and you may get your distro packaging for free. (I know Debian's attitude on developers doing their own packaging seemed to be "Don't touch that. Only we know how to do it properly" last time I asked.)

This is also my personal favourite because one of the platforms I play games on is something nobody closed-source supports. (Linux without Android running on ARM chips. Stuff like the OpenPandora and the Raspberry Pi.)

It's also the simplest option for you because you can officially support only the most recent versions of the top 4 or 5 distros and, as long as the community can do its own patching right as they need to, people will generally forgive you if the game breaks on older or more esoteric platforms. There's just no way you'll be able to support every single Linux platform out there, but there already OpenPandora ports of open-source engine rewrites like ScummVM and the Raspberry Pi just got a build of OpenTTD, a Transport Tycoon Deluxe re-implementation capable of using the original data files.

Share this post


Link to post
Share on other sites
Sorry I didn't respond right away, I had a bit of an evening. Anyway, thanks for your response -the reason your other replies frustrate me is because usually the only reason I get into these discussions is to understand a position better, and well... you didn't seem to be attempting to understand mine, before. I don't think we're actually a million miles away from each other, it's just that I happen to disagree with the 'Always the same' cynicism. For a start, Tim and Co ARE the management here, and I'd be very surprised if they were even in the slightest bit interested in gathering any more personal data than that which is used to deliver the rewards. Maybe I'm wrong there, but it seems to me that 'always the same' is needlessly cynical. And I understand the value of assuming the worst here, but not to such a degree that legitimate uses of data are closed off or hobbled.

Perhaps making it opt-in isn't a big deal - perhaps it is, there haven't been any studies I'm aware of that really look at how it might affect the sample, so we're really just guessing on that one. But my main point was simply that starting the discussion on the assumption that collecting data is an inherently suspicious activity is, in many ways, as unhelpful as expecting users to give up their personal data unquestioningly. I think there's a good middle ground to be found, and I think that it's possible to talk about these things sensibly and without blanket statements.

I really do see your point - and there are cetainly people who are overprotective about stuff like that. But I don't think force-feeding them something they don't want to is the right way. Enough companies already force the user to thing they don't want: Always On, no second-hand games, spying out their system.

My point: A good developer should not try to increase the general acceptance of such behaviour - otherwise it will get more and more difficult to convince people that not every company is awsome (like DF obviously is) and that users should care about their data.

And for opt-in vs. opt-out my opinion is this: If a single person like Tim can convince nearly 90.000 people to pay up front for a game they that wasn't even in the making, than such a person could surely convince people to opt-in if he has a valid reason for asking.

I would be totaly OK with them collecting data if it's voluntarily and transparent and they have a valid point for collecting the data.

I think something like that could convince an old data-mining hater like myself to make an exception:

uw8NH.png

Just an idea.

So sorry, for being cynical, but I guess I get as passionate when it comes to stuff like that than you do.

Share this post


Link to post
Share on other sites
And also: Numbers lie. You don't know how was playing at the time (the main player, his/her partner, a child), you don't know if the player resolved to use a walkthru just after a few minutes and misinterpret a short solving time as a success whereas in reality the player may have been completely clueless.

Most of these issues are improved by simply having a larger sample size. Outliers are excluded from statistical analyses for a reason. Numbers don't lie, they're just points on a line. Bad analysis leads to bad conclusions. Data collection needs to be done carefully, you need to know what you're looking at to make sense of it.

Also, these sorts of metrics generally shouldn't drive your decisions directly, but they can be incredibly useful in identifying the places where your attention should be focused. The data highlights potential problems, but you absolutely need to examine the context.

Even if they only collect this data during the Beta, it's still valuable data to collect.

I second that! There is a wealth of information you can gather from data, as long as you have a large enough dataset and a clear understanding of what you are looking for.

Share this post


Link to post
Share on other sites
Sorry I didn't respond right away, I had a bit of an evening. Anyway, thanks for your response -the reason your other replies frustrate me is because usually the only reason I get into these discussions is to understand a position better, and well... you didn't seem to be attempting to understand mine, before. I don't think we're actually a million miles away from each other, it's just that I happen to disagree with the 'Always the same' cynicism. For a start, Tim and Co ARE the management here, and I'd be very surprised if they were even in the slightest bit interested in gathering any more personal data than that which is used to deliver the rewards. Maybe I'm wrong there, but it seems to me that 'always the same' is needlessly cynical. And I understand the value of assuming the worst here, but not to such a degree that legitimate uses of data are closed off or hobbled.

Perhaps making it opt-in isn't a big deal - perhaps it is, there haven't been any studies I'm aware of that really look at how it might affect the sample, so we're really just guessing on that one. But my main point was simply that starting the discussion on the assumption that collecting data is an inherently suspicious activity is, in many ways, as unhelpful as expecting users to give up their personal data unquestioningly. I think there's a good middle ground to be found, and I think that it's possible to talk about these things sensibly and without blanket statements.

I really do see your point - and there are cetainly people who are overprotective about stuff like that. But I don't think force-feeding them something they don't want to is the right way. Enough companies already force the user to thing they don't want: Always On, no second-hand games, spying out their system.

My point: A good developer should not try to increase the general acceptance of such behaviour - otherwise it will get more and more difficult to convince people that not every company is awsome (like DF obviously is) and that users should care about their data.

And for opt-in vs. opt-out my opinion is this: If a single person like Tim can convince nearly 90.000 people to pay up front for a game they that wasn't even in the making, than such a person could surely convince people to opt-in if he has a valid reason for asking.

I would be totaly OK with them collecting data if it's voluntarily and transparent and they have a valid point for collecting the data.

I think something like that could convince an old data-mining hater like myself to make an exception:

uw8NH.png

Just an idea.

So sorry, for being cynical, but I guess I get as passionate when it comes to stuff like that than you do.

Sure. Why not? I think probably this sort of project, where people have given their money on the promise that a game would get made, has a better chance than most at getting people to opt in. I do still think that we don't really know how opt in / opt out systems affects the sample, but certainly it's the sort of thing applied statisticians think about.

And since some of the point of giving us access to the beta is to gather this kind of data, it would seem sensible to me to make it so that at the very least the beta collects usage data automatically. I think we have to understand that if we're playing a beta, part of what we're doing is helping them to polish the game, and collecting this data is a part of that, and it's best if that data set is as complete as possible. Later on, when the game is out and they know it works, I guess it becomes less important to try to get every bit of usage data from every person.

Share this post


Link to post
Share on other sites
Sign in to follow this  

×
×
  • Create New...