While a one-time fee seems preferable from a customer-standpoint, I personally prefer annual subscription fees. It allows for a potentially lower initial cost, making it more accessible to potential customers, but--more importantly--provides an obvious recurring revenue model for the author, hopefully implying on-going development. Ideally you would retain access to the app if your annual subscription lapses, but could receive upgrades after reviving your subscription. Whenever there is a one-time fee for an "average" app (no offense intended), I always wonder how the author can afford to keep updating it in the future.
Thank you. This is encouraging to hear from a potential user. There may be a middle ground where new features are sold separately (specially feature requests). Having said that, everything you get today with v1 will remain covered by what you paid for the app. No rug-pulling ever to force folks into a subscription.
It is how Beorg does it - they have a subscription covering everything, but users can also buy singe features. However, I imagine that at some point the coding will get quite complex - developer has to build a couple of feature toggles and ensure that they work well in every imaginable combination.
Wow, a fellow twirler! I too strongly consider the weight distribution and "twirl-ability" of my pens. In fact, I have my favourite writing pens, but I always keep a Pilot G2 because it's been my favourite twirling pen for many years.
This whole project continue to be a big love-fest to retro gaming. I love the idea of building simple (or not!) retro-style games for a hand-held device. Hopefully Pulp games will be playable in the browser, so people will be able to try the games even if they didn't order a Playdate, or until their order arrives.
I don't really have any game dev experience, but i've been hacking around in Love2D to try building basic games with Lua. Pulp sounds like a great way to get going, and I'm excited to try it! Love to see what a bunch of creative developers are going to come up with.
> Hopefully Pulp games will be playable in the browser
Prediction: the Pulp games won't be any fun in a browser. You'd be missing what makes the Playdate fun (the device) and the obvious understanding that there are constraints to what can be made for it, and instead you'd be playing a clunky game on a supercomputer.
I think they'd be foolish to allow the games to be played in the browser.
> This whole project continue to be a big love-fest to retro gaming.
You can buy Gameboy-lookalike devices in any toystore for a few bucks. I personally don't understand the rage, although I must admit that I was never a big fan of computer games to begin with.
Most of these are too hard to deal with. Also developing for these devices is a huge pain the ass.
Im excited for this device because its taken game dev as a first citizen. This toy looks to be more about game dev than it is about game play. While play is important part of the eco system that market is soo saturated from AAA billion dollar companies all the way to obscure Gameboy-lookalike devices.
But game dev, and particularly game dev for a device is still a difficult and underserved (I hope for the success of this company) market.
I've said this before, but if they treat this like a physical fantasy console, then judging by the success of pico 8 I don't think they'll have much of an issue with success.
I use Mou every day as well. But the goal of this project seems very vague. Exactly what is going to be added in the "1.0" release? Mou works pretty well for me right now. What is going to be added that will make it worth my while sponsoring this project?
The project vaguely states: "We'll pick the most wanted features from our contributors, implement them in 1.0." But there needs to be a little more meat here. What are some examples of the types of features you are considering? What are the new killer features that will be coming?
I agree, in its current form I don't have any issues regarding bugs or stability, but assuming Yosemite support will be needed some time soon, as well as potentially a Mac App Store integration.
Other than that, I'd say it's a good candidate for a 1.0.0 release, so I'm not sure exactly what the need for $20k is, unless it's to reimburse for time already spent?
I think that defining your constraints ahead of time is the only way to go. If $6,000, why not $10,000, then $20,000, then you're suddenly at $50,000 because you "had to".
Designing within constraints is really what the essence of design is all about. If you set limits, you must work hard to stay within those limits. The idea that "given unlimited time/money/people I could design the ultimate whatever" is a myth anyhow.
While a one-time fee seems preferable from a customer-standpoint, I personally prefer annual subscription fees. It allows for a potentially lower initial cost, making it more accessible to potential customers, but--more importantly--provides an obvious recurring revenue model for the author, hopefully implying on-going development. Ideally you would retain access to the app if your annual subscription lapses, but could receive upgrades after reviving your subscription. Whenever there is a one-time fee for an "average" app (no offense intended), I always wonder how the author can afford to keep updating it in the future.